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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Chair  of  the  National  Institute  of 
Standards  and  Technology  (NIST)  Workshop  for  Implementors  of  Open  Systems  Interconnection  (OSI). 

This  part  replaces  the  previously  existing  chapter  on  this  subject.  There  is  no  significant  technical  change 
from  this  text  as  previously  given. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 


Part  1  -  General  Information 


0  Introduction 

This  document  records  current  stable  implementation  agreements  of  OSI  protocols  among  the  organizations 
participating  in  the  NIST  Workshop  for  Implementors  of  OSI.  Stable  in  the  context  of  this  document  means 
the  following: 

a)  the  agreements  are  based  on  final  standards  (e.g.,  ISO-IS  or  CCITT  Recommendations)  or  nearly 
final  (e.g.,  ISO-DIS)  with  no  significant  changes  expected, 

b)  the  agreements  have  been  approved  by  the  NIST  Workshop  Plenary  for  progression  from  the 
Working  Agreements  document  to  this  document  after  a  period  of  review.  These  agreements  are 
considered  final;  the  only  changes  allowed  will  be  clarifications,  and  certain  Technical  and  Alignment 
errata.  These  changes  must  have  the  strong  support  of  vendors,  and  be  justifiable. 

For  these  reasons,  the  agreements  are  considered  advanced  enough  for  use  in  product  and  test  suite 
development.  This  means  that  readers  can  use  this  text  as  a  t>asis  for  procurement  references  for  OSI 
products.  All  of  the  text  in  this  document  is  considered  stable  as  defined  above. 

Future  releases  of  these  Stable  Agreements  will  add  and/or  extend  functionality  offered  by  this  edition  and 
version.  When  required,  new  versions  will  be  Introduced  on  a  yearly  basis.  It  is  the  NIST  Workshop  intent 
that  new  versions  of  this  Stable  Agreements  document  will  be  compatible  with  the  present  version.  If  this 
proves  impractical,  the  agreements  will  attempt  to  provide  mechanisms  and  guidelines  which  maximize 
interoperability.  Furthermore,  it  is  the  intent  that  these  stable  agreements  be  maintained  via  the  Errata 
process  as  long  as  is  appropriate.  For  the  subject  area,  interworking  information  and  other  useful  advice 
to  the  reader  is  given  as  appropriate.  Specific  "defect  report"  information  (including  extent  of  applicability) 
is  provided  in  designated  portions  of  each  Part. 


1  Scope 

Agreements  text  is  either  in  this  Stable  Document  (Stable)  or  in  the  aligned  Working  Document  (not  yet 
stable).  It  is  a  goal  that  the  same  text  not  appear  in  the  same  position  in  both  documents  at  once  (except 
for  part  1).  Modifications  to  a  version  reflect  very  recent  stable  functionality  as  well  as  editorial,  technical, 
and  alignment  errata,  all  applied  to  the  previous  edition. 

The  intended  audience  for  this  document  is  composed  of  those  individuals  who  are  interested  in  Stable 
Implementation  Agreements  for  OSI  protocols.  Each  part  of  the  document  covers  a  different  subject  area, 
and  the  parts  are  presented  so  as  to  present  a  consistent  and  unified  approach.  The  format  of  V4  follows 
the  ISO  directives  whenever  possible. 

The  corresponding  and  aligned  document,  "Working  Implementation  Agreements  for  OSI  Protocols  dated 
Juno  1001,"  records  agreements  which  are  not  yet  considered  stable,  in  the  sense  described  above.  This 
document  will  be  referenced  as  the  "Working  Agreements  Document."  This  Stable  document  is  aligned  with 
the  Working  Agreements  Document  in  the  sense  that  the  structures  are  identical,  and  pointers  are  given  in 
this  Stable  Document  to  work  in  the  Working  Agreements  Document  which  could  become  stable  in  the 
future. 
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The  benefit  of  this  document  to  the  reader  is  that  it  gives  a  complete  accounting  of  current  stable 
agreements.  Minor  changes  (Errata)  to  these  agreements  will  be  issued  in  replacement  page  format.  These 
errata  will  only  be  applied  to  the  current  version. 

Currently  efforts  are  underway  to  define  worldwide  technically  harmonized  profiles.  The  goal  is  to  create 
a  consolidated  global  market  for  OSI  products.  This  means  that  vendors  can  sell  to  a  larger  market,  and 
users  can  procure  products  from  a  variety  of  vendors  around  the  world.  Agreements  in  this  document  are 
likely  to  be  used  in  these  alignment  efforts. 

Version  4  (this  version)  Is  backwards  compatible  with  Version  3  to  the  maximum  extent  possible.  Version 
4  includes  all  of  the  material  from  Version  3,  (modified  by  errata)  as  well  as  new  stable  material  from  the 
previous  year;  important  new  functional  additions  from  Version  3  are  in  the  areas  of  FDDI,  Network  Layer 
aspects,  Transport  Layer  aspects,  Network  Management,  MMS,  and  features  of  1988  based  X.400 
agreements. 


2     Normative  References 

See  succeeding  parts. 


3  Definitions 

See  succeeding  parts. 


4     Purpose  of  the  Workshop 

In  February,  1983,  at  the  request  of  industry,  NIST  organized  the  NIST  Workshop  for  Implementors  of  OSI 
to  bring  together  future  users  and  potential  suppliers  of  OSI  protocols.  The  Workshop  accepts  as  input  the 
specifications  of  emerging  standards  for  protocols  and  produces  as  output  agreements  on  the 
implementation  and  testing  particulars  of  these  protocols.  This  process  is  expected  to  expedite  the 
development  of  OSI  protocols  and  promote  interoperability  of  independently  manufactured  data 
communications  equipment. 


Stable  Implementation 
Agreements  for  Open  Systems 
Interconnection  Protocols: 
Part  2  -  Subnetworks 


Output  from  the  September  1991  NIST  Workshop  for 
Implementors  of  OSI 


SIG  Chair: 
SIG  Editor: 


Fred  Burg,  AT&T 
Kristy  Brown,  NSC 


Workshop  Editor:  Brenda  Gray 


Part  2  -  Subnetworks 


September  1991  (Stable) 


Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Lower  Layers  Special  Interest  Group 
(LLSIG)  of  the  National  Institute  of  Standards  and  Technology  (NIST)  Workshop  for  Implementors  of  Open 
Systems  Interconnection  (OSI).  See  Procedures  Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject. 

Annexes  A  and  B  are  for  information  only. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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0  Introduction 

This  ohaptor  |a|  provides  agreements  about  subnetwork  services  used  in  support  of  the  OSI  Networl<  Layer. 


1  Scope 

These  agreements  cover  subnetwork  types  including  local  area  networks,  packet  switched  networks,  circuit 
switched  networks,  ISDN,  and  others. 


2     Normative  References 


2.1  CCITT 

[1]       Recommendation  1.231  (Blue  Book,  1988),  Circuit-Mode  Bearer  Service  Categories. 

[2]       Recommendation  1.232  (Blue  Book,  1988),  Packet-Mode  Bearer  Service  Categories. 

[3]  Recommendation  1.431  (Blue  Book,  1988),  Primary  Rate  User-Network  Interface  -  Layer  1 
Specification. 

[4]  Recommendation  Q.921  (1.441)  (Blue  Book,  1988),  ISDN  User-Network  Interface,  Data  Link  Layer 
Specification. 

[5]  Recommendation  Q.931  (1.451)  (Blue  Book,  1988),  ISDN  User-Network  Interface  Layer  3 
Specification  for  Basic  Call  Control. 

[6]  Recommendation  X.25  (Yellow  Book  1980),  Interface  Between  Data  Terminal  Equipment  (DTE)  and 
Data  Circuit  Terminating  Equipment  (DCE)  for  Terminals  Operating  in  the  Packet  Mode  on  Public 
Data  Networks. 

[7]  Recommendation  X.25  (Blue  Book,  1988),  Interface  Between  Data  Terminal  Equipment  (DTE)  and 
Data  Circuit-Terminating  Equipment  (DCE)  for  Terminals  Operating  in  the  Packet  Mode  and 
Connected  to  Public  Data  Networks  by  Dedicated  Circuit. 

[8]       Recommendation  X.31  (Blue  Book,  1988),  Support  of  Packet  Mode  Terminal  Equipment  by  an  ISDN. 
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2.2  ISO 

[9]       ISO  7776,  Information  processing  systems  -  Data  communication  -  High-level  Data  Link  Control 
Procedures  -  Description  of  the  X.25  LAPB-compatible  DTE  data  link  procedures. 

[10]     ISO /lEC  8208  Edition  2,  Information  technology  -  Data  communications  -  X.25  Packet  layer  protocol 
for  data  terminal  equipment. 

[11]     ISO  8802-2,  Information  processing  systems  -  Local  area  networks  -  Part  2:  Logical  link  control. 

[12]     ISO  DIS  8802-3,  Information  processing  systems  -  Local  area  networks  -  Part  3:  Carrier  sense 
multiple  access  method  with  collision  detection  (CSMA/CD)  and  physical  layer  specifications. 

[13]      ISO  DIS  8802-4,  Information  processing  systems  -  Local  area  networks  -  Part  4:  Token-passing  bus 
access  method  and  physical  layer  specifications. 

[14]      ISO  8802-5,  Information  processing  systems  -  Local  area  networks  -  Part  5:  Token  ring  access 
method  and  physical  layer  specifications. 

[15]      ISO  9314-1 ,  Information  processing  systems  -  Fibre  distributed  data  interface  (FDDI)  -  Part  1:  Token 
ring  physical  layer  protocol  (PHY). 

[16]      ISO  9314-2,  Information  processing  systems  -  Fibre  distributed  data  interface  (FDDI)  -  Part  2:  Token 
ring  media  access  control  (MAC). 

[17]      ISO  DIS  9314-3,  Information  processing  systems  -  Fibre  distributed  data  interface  (FDDI)  -  Part  3: 
Physical  layer  medium  dependent  (PMD). 

[10]     J$0 10039,  tnformatfop  Technotogy  -  LopatAresc  N^tworics  -  MAC  Serviv&  Q^finMott 


2.3  ANSI 

[19]      ANSI/IEEE  802.2,  Logical  Link  Control,  1987. 

[20]     ANSI/I  EEE  802.3,  Carrier  Sense  Multiple  Access  with  Collision  Detection  (CSMA/CD)  and  Physical 
Layer  Specifications,  1985. 

[21]      ANSI/IEEE  802.3  Supplement  a,  MAU  and  Baseband  Medium  Specification,  Type  10BASE2  (Section 
10),  1988. 

[22]     ANSI /IEEE  802.3  Supplement  b.  Broadband  MAU  and  Broadband  Medium  Specifications,  Type 
10BROAD36  (Section  11),  1988. 

[23]     ANSI/IEEE  802.3  Supplement  c.  Repeater  Unit  for  10  Mb/s  Baseband  Networks  (Section  9),  1988. 

[24]     ANSI/IEEE  802.3  Supplement  e,  Physical  Signaling,  Medium  Attachment,  and  Baseband  Medium 
Specifications,  Type  1  BASES  (Section  12),  1988. 
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[25]      ANSI/IEEE  802.4,  Token-Passing  Bus  Access  Method  and  Physical  Layer  Specifications,  Draft 
1987. 

[26]     ANSI/IEEE  802.5,  Token-Ring  Access  Method  and  Physical  Layer  Specifications,  1986. 

{27]  ANS  T1.103,  Carrier  to  Cuotomor  Inctallation — DSl  Motallic  Intorfaco. 

{27|    ANS  Ti.4oa-i^.  ISDN  Prkmty  M&tf^im  -  Oostomer  imt^Us^on  M^Mic  irtt6rfac0$  -  i^^if#lj[ 

[28]     ANS  T1.601,  Integrated  Sen/ices  Digital  Network  (ISDN)  -  Basic  Access  Interface  for  Use  on 
Metallic  Loops  for  Application  on  the  Network  Side  of  the  NT  (Layer  1  Specification). 

[29]     ANS  T1 .602,  Integrated  Sen/ices  Digital  Network  (ISDN)  -  Data-Link  Layer  Signalling  Specification 
for  Application  at  the  User-Network  Interface. 

[30]     ANS  T1 .605,  Integrated  Services  Digital  Network  (ISDN)  -  Basic  Access  Interface  for  S  and  T 
Reference  Points  -  Layer  1  Specification. 

[31]     ANS  T1.607,  Telecommunications  -  Digital  Subscriber  Signaling  System  #7  -  Layer  3  Signaling 
Specification  for  Circuit  Switched  Bearer  Sen/ice. 

[32]     ANS  T1 .608,  Telecommunications  -  Digital  Subscriber  Signaling  System  #  7  -  Layer  3  Signaling 
Specification  for  Packet  Switched  Bearer  Sen/ice. 

[33]     ANS  X3. 1 39,  Fiber  distributed  data  interface  (FDDI)  -  Token  ring  media  access  control  (MAC) ,  1 987. 

[34]     ANS  X3. 1 48,  Fiber  distributed  data  interface  (FDDI)  -  Token  ring  physical  layer  protocol  (PHY) .  1 988. 

[35]     ANS  X3.166,  Fiber  distributed  data  interface  (FDDI)  -  Physical  layer  medium  dependent  (PMD), 
1989. 


3  Status 

This  version  was  completed  in  December  1 990. 
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Errata 

NOTE  -  This  clause  may  contain  "defect  report"  and  resolutions  material,  and  the  versions  of  Implementor's 
Agreements  to  which  this  material  applies. 


5     Local  Area  Networks 

5.1      IEEE  802.2  Logical  Link  Control 

The  following  decisions  have  been  reached  with  respect  to  this  protocol: 

a)  Link  Sen/ice  Access  Point  (LSAP): 

1)  The  code  below  shall  be  used  to  address  systenns  using  Network  Layer  protocols 
identified  by  ISO  TR  9577  (e.g.,  ISO  8473,  ISO  8208).  Note  that  bit  zero  is  transmitted  first; 

2)  The  most  significant  bit  is  bit  7,  thus  this  bit  pattern  represents  hexadecimal  FE  (see 
figure  1  below); 

b)  Type  and  Class: 

1)  Only  the  connectionless  type  1,  class  I  IEEE  802  link  service  will  be  used. 


Figure  1  -  LSAP  bit  pattern 


5.2      IEEE  802.3  CSMA/CD  Access  Method 

The  following  implementation  agreements  have  been  reached  with  respect  to  the  IEEE  802.3  CSMA/CD 
Access  Method  and  Physical  Layer  Specifications: 

a)  The  address  length  shall  be  48  bits; 

b)  For  a  data  packet  of  LLC  data  length  of  n  octets,  the  length  of  the  pad  field  is  as  follows: 

1)  max(0,  minFrameSize-(8n  +  2(addressSize)  +  48))  bits. 
The  following  implementation  agreements  have  been  reached  with  respect  to  10  BROAD  36  Networks: 
a)  Single  Cable  Networks: 

1)  The  translator  frequency  shall  be  192.25  Mhz; 
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2)  The  channel  allocations  are  as  follows: 
a)  Reverse  Channels: 

1)  T12.  T13,  T14 


September  1 991  (Stable) 
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2)  T13.  T14.  2' 

3)  T14,  2',  3' 

4)  2',  3",  4" 

5)  3',  4",  4A* 

6)  4',  4A',  5' 
b)  Forward  Channels: 

1)  L,  M,  N 

2)  M,  N.  0 

3)  N,  O,  P 

4)  O,  P,  Q 

5)  P,  Q.  R 

6)  Q,  R.  S 
b)  Dual  Cable  Networks: 

For  nontranslated  dual  cable  networks  forward  and  reverse  frequencies  are  the  same.  Permissible 
channel  allocations  are  listed  below: 

1)  T12,  T13,  T14 

2)  T13,  T14.  2' 

3)  T14,  2',  3' 

4)  2',  3',  4' 

5)  3',  4',  4A' 

6)  4',  4A',  5' 

7)  L,  M,  N 

8)  M,  N.  0 

9)  N,  0,  P 

10)  0,  P,  Q 
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11)  Q,  R.  S 

c)  When  both  IEEE  802.4  and  IEEE  802.3  10  BROAD  36  networks  coexist  on  the  broadband  cable 
system  the  preferred  channel  allocations  are  as  follows: 

1)  Reverse: 

a)  T12,  T13,  T14  -  IEEE  802.3; 

b)  6',  FM1'  -  IEEE  802.4; 

c)  3',  4'-  Channels  reserved  for  future  use; 

d)  4A',  5'  -  Channels  reserved  for  future  use; 

2)  Forward: 

a)  L,  M,  N  -  IEEE  802.3; 

b)  T,  U  -  IEEE  802.4; 

c)  P,  Q  -  Channels  reserved  for  future  use; 

d)  R,  S  -  Channels  reserved  for  future  use. 

The  following  Implemer^tatjon  agreements  have  been  reached  with  respect  to  10  BASE-T  netw<wks; 


a) 

Auto«par 

"'^peater  port  wluch  connects  10  BASE-T  links  eltfjer  through  an  external  or 

mptement  thd  autc^-partltlon  dhd  rdconrtdctiorts  algorithm  &^  d^n&d  \t\  IEEE 

5.3      IEEE  802.4  Token  Bus  Access  Method 

The  following  options  are  agreed  to  with  respect  to  Draft  J  of  token  bus: 

a)  Data  Rate: 

1)  10  Mb  (Broadband); 

2)  5  Mb  (Carrierband); 

b)  Addressing:  48  bit; 

c)  The  ImeOption,  Priority  Mechanism,  shall  be  implemented; 
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d)  Broadband  Channel  Assignments  are  as  follows: 

1)  Forward: 

a)  P 

b)  Q 
0)  R 

d)  S 

e)  T 

f)  U 

2)  Reverse: 

a)  3' 

b)  4' 

c)  4A' 

d)  5' 

e)  6' 

f)  FM1'. 


5.4      IEEE  802.5  Token  Ring  Access  Method 

The  following  implementation  agreements  have  been  reached  with  respect  to  the  IEEE  Standard  802.5, 
Token  Passing  Ring  Access  Method  and  Physical  Layer  specification: 

a)  The  data  signalling  rate  shall  be  4  Mbit/s; 

b)  The  address  length  shall  be  48  bits; 

c)  The  message  priority  (PM)  of  the  AMP  data  unit  shall  be  7; 

d)  The  ALL_STATIONS_THIS_RING_ADDRESS  shall  be  X'COOOFFFFFFFF'; 
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e)  The  TRR  value  shall  be  4  milliseconds; 

f)  The  THT  value  shall  be  8.9  milliseconds; 

g)  The  TQP  value  shall  be  20  milliseconds; 

h)  The  TVX  value  shall  be  10  milliseconds; 

i)  The  TNT  value  shall  be  2.6  milliseconds; 
j)  The  TAM  value  shall  be  7  seconds; 

k)  The  TSM  value  shall  be  15  seconds; 

I)  The  MAC  Information  field  (l-field)  shall  be  defined  as  follows  in  figure  2  below. 
Sequences  are  as  follows: 

1)  Starting  Sequence  includes:  SD,  AC,  FC,  DA,  SA; 

2)  Ending  Sequence  includes:  FCS,  ED,  FS; 

m)  With  the  above  timer  and  MAC  l-field  definitions,  the  following  limits  are  defined: 

1)  Protocol  limits  the  l-field  to  a  maximum  of  4425  bytes; 

2)  All  stations  shall  support  l-fields  that  have  a  minimum  of  one  byte  and  a 
maximum  of  at  least  2000  bytes. 


starting  Sequence 


I-Field 


End  Sequence 


Figure  2  -  l-Field  Format 
5.5      Fiber  Distributed  Data  Interface  (FDDI) 
5.5.1       Token  Ring  Media  Access  Control  (MAC,  X3.1 39-1 987) 

The  following  are  implementation  agreements  with  respect  to  FDDI  MAC: 

a)  The  address  length  shall  be  48  bits; 

b)  There  shall  be  some  manual  or  programmatic  means  of  resetting  stations  and 
concentrators  to  the  values  specified  as  defaults  herein  or  in  X3. 139-1 987; 
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c)  The  default  value  of  T_Max  shall  be  at  least  165  milliseconds  and  not  more  than  200 
milliseconds; 

d)  The  default  value  of  T_Req  shall  be  equal  to  either  T_MAX  or  T_Req_f\/lax^  whichever  is  less; 

e)  All  FDDI  stations  shall  process  lnfo_Fields  of  0  to  4478  bytes.  The  frame  is  defined  as  follows 
in  Figure  3: 

f)  Stations  shall  not  use  restricted  token  service. 


SD 


FC 


DA 


SA 


Info 


PCS  ED 


FS 


Figure  3  -  FDDI  FRAME  FORMAT 


P:  Preamble 

-  16  Idle  Symbols  for  Transmitting 

-  >  =  6  Idle  Symbols  for  Copying 

-  >  =  2  Idle  Symbols  for  Repeating 
SD:  Starting  Delimiter  (2  Symbols,  JK) 
FC:      Frame  Control  (2  Symbols) 

DA:      Destination  Address  (12  Symbols) 
SA:      Source  Address  (12  Symbols) 
INFO:   Information  Field  (=  <8956  Symbols) 
PCS:    Frame  Check  Sequence  (8  Symbols) 
ED:      Ending  Delimiter  (1  Symbol) 
FS:      Frame  Status  (3  Symbols) 


5.5.2       Token  Ring  Physical  Layer  (PHY,  X3.1 48-1 988) 

The  following  implementation  agreement  is  with  respect  to  the  FDDI  PHY  specifications: 


T_Req_Max  is  defined  in  the  Ring  Management  (RMT)  section  of  Station  Management.  It  is  used 
in  the  resolution  of  duplicate  address  problems  which  prevent  ring  initialization.  Stations  which  have 
detected  that  they  are  duplicates  during  ring  initialization  take  action  to  make  sure  that  they  lose 
the  Claim  process  to  other  stations  having  a  T_Req  value  less  the  jthan  T_Req_Max.  T_Req_Max 
is  specified  in  SMT  to  have  a  value  ^  «  167.8  milliseconds. 
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1  The  average  delay,  that  is  the  time  between  when  a  station  receives  a  Starting  Delimiter  (JK  symbol 
pair)  beginning  a  valid  frame  until  it  repeats  that  Starting  Delimiter,  when  that  Starting  Delimiter  is 
preceded  by  a  sequence  of  a  valid  frame  followed  by  50  Idle  Symbols  shall  not  exceed: 

1  microsecond  in  a  station,  and 

1  microsecond  times  the  number  of  ports  in  a  concentrator,  in  addition  to  the  delays 
contributed  by  the  active  slaves  of  the  concentrator. 

The  measurement  method  described  above  allows  a  consistent  repeatable  measurement,  however 
it  does  not  measure  maximum  possible  delay.  When  the  delay  is  one  microsecond  as  measured 
above,  the  maximum  effective  delay  contribution  component  which  can  result  is  1.164 
microseconds.  This  number,  not  one  microsecond,  should  be  used  per  PHY  to  compute  maximum 
possible  network  delay. 


5.5.3       Physical  Layer  Media  Dependent  (PMD,  X3.1 66-1 989) 

The  following  implementation  agreements  are  with  respect  to  the  FDDI  PMD  specification: 

1  Stations  shall  repeat  all  valid  packets  under  all  signal  conditions  specified  in  section  5.2  of  X3.166- 
1989,  "Active  Input  Interface",  with  a  bit  error  rate  (BER)  of  not  more  than  2.5  x  10'^°; 

2  Stations  shall  repeat  all  valid  packets  under  all  signal  conditions  specified  in  section  5.2,  "Active 
Input  Interface",  except  that  the  Minimum  Average  Power  shall  be  -29  dBm  (2  dB  above  the 
specified  minimum),  with  a  BER  of  not  more  than  lO  'l 


6     Wide  Area  Networks 


6.1  CCITT  Recommendation  X.25 

The  procedures  required  to  describe  the  DTE  side  of  a  DTE/DCE  interface  for  systems  attached  to  sub- 
networks providing  an  X.25  interface  shall  be  as  defined  in  ISO  7776  and  ISO  8208  and  as  supplemented 
below.  (These  procedures  shall  also  apply  to  a  DTE  operating  on  a  DTE/DTE  interface.) 

6.2  ISO  7776 

ISO  7776  is  used  as  the  Layer  2  Protocol  with  the  agreements  defined  below: 
a)  Address  assignment  information  is  as  follows: 
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1)  DTE  =  A  (=11000000  binary); 

2)  DCE  =  B  (=10000000  binary); 

3)  On  a  DTE/DTE  interface,  one  of  the  DTEs,  by  a  prior  agreement,  shall  use 
the  DCE  address; 

b)  The  modulus  shall  be  8; 

c)  A  window  size  (k)  of  7  shall  be  supported.  In  addition,  other  window  sizes  may 
also  be  supported; 

d)  The  Multilink  Procedures  are  excluded. 


6.3      ISO  8208 

The  elements  of  ISO  8208  applicable  for  use  depend  on  the  OSI  role  of  ISO  8208  (i.e.,  provision  of 
CONS,  support  of  CLNP).  Independent  of  the  role,  ISO  8208  is  used  as  the  Layer  3  protocol,  with  the 
following  agreements: 

a)  Virtual  Call  Service; 

b)  any  mutually  agreed  window  and  packet  size,  however,  all  DTEs  must  be  capable 
of  supporting  a  window  size  of  2,  a  packet  size  of  128  octets,  and  a  sequence  number 
modulus  of  8; 

c)  a  DTE  must  be  capable  of  receiving  the  Flow  Control  Parameter  Negotiation 
Facility  and  responding  appropriately  (per  ISO  8208); 

d)  The  Basic  RPOA  Selection  Facility  shall  be  implemented  and  its  use  or  non-use 
selectable  on  a  per  virtual  call  basis. 

When  ISO  8208  is  used  to  support  CONS,  the  optional  user  facilities  in  Clause  5.1  of  ISO  8878  shall 
also  be  supported. 

When  ISO  8208  is  used  to  support  CLNP  (when  providing  the  CLNS),  Permanent  Virtual  Circuit  Service 
may  also  be  used. 


7     Integrated  Services  Digital  Networks  (ISDN) 
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7.1  Introduction 

This  clause  defines  Implementation  Agreements  for  packet-data  transfer  in  an  ISDN  context.  The 
agreements  provide  a  set  of  procedures  for  accessing  an  ISDN  so  that  end  systems  implemented 
according  to  these  agreements  can  obtain  ISDN  services  and  can  successfully  interoperate. 

The  agreements  are  not  meant  to  preclude  vendors  from  implementing  additional  procedures  as  long  as 
they  do  not  create  system  interoperability  problems.  Capabilities  will  vary  from  ISDN  to  ISDN  and 
procedures  beyond  those  included  here  may  be  necessary  to  request  and  utilize  network  services  more 
effectively  and  fully. 

The  agreements  cover  two  fundamental  ISDN  services  for  X.25  packet  mode  ISDN  terminals,  namely, 

The  ISDN  provides  a  circuit-mode  (Layer  1)  connection  either  on  demand  ("switched")  or 
permanently  ("dedicated  circuit").  A  general  description  of  the  corresponding  ISDN  64 
Kbps  circuit-mode  bearer  service  is  described  in  CCITT  Recommendation  1.231.  The 
circuit-mode  connection  is  between  an  X.25  ISDN  terminal  and  (i)  a  PSPDN,  or  (ii) 
another  X.25  ISDN  terminal.  The  circuit-mode  connection  to  a  PSPDN  corresponds  to 
CASE  A  of  CCITT  Recommendation  X.31. 

The  ISDN  provides  the  X.25  virtual  circuit  service.  A  general  description  of  this  service  is 
given  in  CCITT  Recommendation  1.232.  This  case  corresponds  to  CASE  B  of  CCITT 
Recommendation  X.31. 

Figures  4  and  5  give  the  agreed  stacks  for  X.25  packet  transfer  over  D  and  B  channels,  respectively. 
Some  particular  aspects  are  given  below: 

a)  The  packet  data  transfer  is  on  a  B  channel  of  a  Basic  Access  or  a  Primary  Rate 
Interface,  in  CASE  II,  it  can  be  on  a  D  channel  of  a  Basic  Access  Interface; 

b)  The  layer  2  procedures  are  LAPB  (ISO  7776)  on  a  B  channel  and  LAPD  (CCITT 
Recommendation  Q.921)  on  a  D  channel; 

c)  X.25  PLP  (ISO  8208)  procedures  are  used,  including  the  setting  up  and  clearing  of 
virtual  calls; 

d)  Q.921  and  Q.931  procedures  on  a  D  channel  are  used  for  access  signaling,  when 
appropriate,  to  select  the  B  or  D  channel  for  packet  data  transfer  and  for  establishing 
and  releasing  a  physical  path  in  the  ISDN; 

e)  Refer  to  part  3  for  the  specification  of  methods  for  providing  OSI  Network  Services. 


12 


CASE  I: 


CASE  II: 


Part  2  -  Subnetworks 


September  1991  (Stable) 


7.2      Implementation  Agreements 

This  clause  gives  Implementation  Agreements  for  individual  ISDN-related  protocols.  The  relevant  protocol 
stacks  are  given  in  figures  4  and  5. 

OS I  LAYER 


Q.931 

ISO  8208 

(1.451) 

(X.25  PLP) 

Q.921 

(1.441) 

(LAPD) 

1  1  ^'l 

D  CHANNEL 

ANS  Tl. 601-1988, 

ANS  Tl. 605-1988 

ADDITIONAL  SIGNALING  PACKET  SWITCHED 

FOR  INCOMING  PACKET*       SIGNALING  AND  INFORMATION 
CALLS  TRANSFER 

*  MAY  BE  NULL 

Figure  4  -  Protocol  Layers  at  S,  T  and  U  reference  points  when  D  Channel  is  used  in  ISDN 
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OS I  LAYER 


Q.931 
(1.451) 

ISO  8208 
(X.25  PLP) 

Q.921 
(LAPD) 

ISO  7776 
(X.25  LAPS) 

D  CHANNEL 


B  CHANNEL 


ANS  Tl. 601-1988,  ANS  Tl. 605-1988 
and  for  Primary  Rate  ANS  T1.40|-19i|i 


 I  I 

Note  1  Note  2 

Figure  5  -  Protocol  Layers  at  S,  T  and  U  reference  points  when  B  Channel  is  used  in  ISDN 
NOTES 

1  This  refers  to  signaling  for  circuit  switched  access  (may  be  null),  as  well  as  additional  signaling  for  incoming 
packet  calls  (may  be  null). 

2  This  refers  to  packet  switched  signaling  and  information  transfer. 

7.2.1  Physical  Layer,  Basic  Access  at  "U" 

ANS  T1 .601  -1988.  "Integrated  Services  Digital  Network-Basic  Access  Interface  for  Use  on  Metallic  Loops  for 
Application  on  the  Network  Side  of  the  NT  (Layer  1  Specification)"  applies. 

7.2.2  Physical  Layer,  Basic  Access  at  S  and  T 

ANS  T1 .605-1 988,  "Integrated  Services  Digital  Network-Basic  Access  Interface  for  S  and  T  Reference  Points- 
Layer  1  Specification"  applies. 


7.2.3       Physical  Layer,  Primary  Rate  at  ^  S,  T,  and  U 

fi^^  Tt,408-t99a,  "ISDN  Primary  Rate  -  Customer  Installation  Metallic  Interfaces  -  Layer  1  Specifrca^orf* 
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Tho  phyoical  layor  is  govornod!  by  ANS  T1.403  1080,  "Carrier  to  Cuotomor  Installation — Motallio  Intorfaoo", 
and  CCITT  Rocommondation  1.431  1088,  "Primary  Rate  User  Network  Intorfacc — Layer  1  Specification" 
subject  to  the  exceptions  given  below: 

Tho  following  portions  of  ANS  J-\A09  1080  shall  bo  deleted: 

a)  Section  5.3.1:  The  bit  rate  tolerance  option  of  ^/  200  bps; 

b)  Section  5.6:  Tho  minimum  pulse  density  of  this  section; 

c)  Section  6.1:  Tho  superframo  format; 

d)  Section  6.3:  Tho  complete  section; 

0)  Section  8.0:  Tho  reference  to  tho  SF  format; 

f)  Section  8.3:  Tho  text  in  paragraph  8.3.1.1  and  footnote  7  (8.3.1.2); 

g)  Section  8.4.1:  Footnote  0; 

h)  Section  0/figure  0:  Provisions  for  tho  use  of  tho  f^J48M  connector; 

1)  Table  2:  This  table; 

j)  Table  3:  The  illustration  in  table  3  of  "Robbed  Bit  Signaling". 
The  following  portions  of  ANS  T1.403  1080  shall  bo  modified: 

a)  Section  5.3.2:  Tho  text  of  this  section  is  replaced  by: 

1)  "The  line  code  is  B8ZS  except  as  noted  in  section  7"; 

b)  Section  7.0:  The  referenco  to  the  pulse  density  requirements  of  section  5.6  is  inappropriate.  Tho 
text  is  replaced  by: 


r  ANSI  accredited  subcommittee  T1E1  is  developing  a  standard  for  tho  ISDN  primary  rato  intorfaoo  at  roforoncG 

\  points  "S"  and  "T"  as  well  as  "U".  Ono  of  tho  aoooptod  guidelines  for  tho  standard  is  consistency  with  ANS 
^^.A03  1089.  It  is  intended  that,  when  this  now  ISDN-unique  standard  is  adopted,  this  agreement  will  bo  modified 
to  roforonce  it  and  will  bo  extended  to  cover  intorfaoos  at  roforonco  points  "S"  and  "T"  as  well  as  "U".  Tho  current 

:  standard  mentioned  is  at  the  default  letter  ballot  level  of  the  draft  document:  T1E1  2/80  016R1.  "ISDN  Primary 

I  Rato  Customer  Installation  Intorfaoos  Layor  1  Spocifioation". 
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1)  'Tho  provioionc  of  Cloar  Channel  Capability  (CCC)  dopondo  upon  tho  uoo  of  tho  B8ZS 
lino  oodo,  though  tho  uoo  of  ZBTSI  io  ono  intorim  mothod  that  may  bo  omployod  by 
agroomont  of  tho  network  and  tho  uoor". 

Tho  provioiono  of  ANS  T1.103  1080  ohall  bo  oupplomontod  by  tho  provioionc  of  CCITT  Roconnmondation 
ir4d4 — Gootion  4.4. 


7.2.4       Data  Link  Layer,  D-Channel 

CCITT  Recommendation  Q.921  (1.441 ).  "ISDN  User-Network  Interface,  Data  Link  Layer  Specification"  applies. 


7.2.5  Signaling 

CCITT  Recommendation  Q.931  (1.451),  "ISDN  User-Network  Interface  Layer  3  Specification  for  Basic  Call 
Control"  applies. 

The  following  agreements  have  been  reached  concerning  the  use  of  Q.931 : 

a)  On  a  Basic  Rate  Interface  supporting  the  ISDN  virtual  circuit  sery/ice,  all  of  Q.931  section  6 
except  for  6.1.1  and  6.2.1  (the  sections  covering  the  circuit-switched  access  case)  shall  apply.  The 
following  sections  also  apply:  2.2,  packet  mode  access  connection  states;  3.2,  messages  for  packet 
mode  access  connection  control;  4-4.5,  section  specifying  general  information  element  handling  and 
encoding;  4.7,  information  elements  for  packet  communications; 

b)  On  a  Primary  Rate  Interface  supporting  the  ISDN  virtual  circuit  service  all  of  Q.931  section  6  shall 
apply  except  for  6.1.1  and  6.2.1  (the  sections  specifying  the  circuit  switched  access  case),  6.1.2.2, 
6.2.2.2  and  6.4.2  (the  sections  specifying  D-Channel  ISDN  Virtual  Circuit  service  case).  The  following 
sections  also  apply:  2.2,  packet  mode  access  connection  states;  3.2,  messages  for  packet  mode 
access  connection  control;  4-4.5,  sections  specifying  general  information  element  handling  and 
encoding;  4.7,  information  elements  for  packet  communications; 

c)  On  a  Basic  or  Primary  Rate  Interface  supporting  the  unrestricted  64-Kbps  circuit-mode  service, 
Q.931  sections  6.1 .1 ,  6.2.1 , 6.4.1  and  6.4.3  shall  apply.  The  following  sections  also  apply:  2.1 ,  circuit 
mode  connection  states;  3.1,  messages  for  circuit  mode  connection  control;  4-4.5,  sections 
specifying  general  information  element  handling  and  encoding. 
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7.2.6       Data  Link  Layer  B-Channel 

The  agreements  on  ISO  7776  specified  in  6.2  shall  apply  here. 

If  the  ISDN  provides  a  circuit-mode  service  between  two  ISDN  packet-mode  devices,  then  the  layer  2 
address  shall  be  assigned  as  follows: 

a)  For  permanent  ("non-switched")  circuit-mode  service,  one  terminal  uses  address  A 
and  the  other  terminal  uses  address  B,  as  arranged  by  prior  agreement; 

b)  For  demand  ("switched")  circuit-mode  service,  the  terminal  originating  the  circuit- 
mode  call  uses  address  A  and  the  other  terminal  uses  address  B. 


7.2.7       Packet  Layer 

The  agreements  on  ISO  8208  specified  in  6.3  shall  apply  here.  When  ISO  8208  is  used  on  the  D- 
Channel,  the  maximum  DATA  packet  size  (i.e.,  actually  the  maximum  size  of  the  User  Data  Field  in  a 
DATA  packet)  shall  be  limited  to  256  octets. 
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Annex  A  (informative) 

Cross  Reference  Between  CCiTT  and  ANSI  Text  Relating  to  ISDN 
Agreements 

This  annex  provides  a  cross-reference  listing  between  those  sections  of  the  CCITT  ISDN 
Recommendations  given  in  clause  7  of  this  document  and  the  sections  of  the  corresponding  ANSI  ISDN 
Standards.  This  appendix  does  not  supersede  clause  7  but  merely  provides  a  pointer  to  those  who  wish 
to  implement  the  ISDN  procedures  based  on  ANSI  Standards. 

A.1      Data  Link  Layer,  D-Channel 


CCITT  Recommendation  Q.921,  which  is  referenced  in  7.2.4  of  this  document,  is  identical  to  ANSI 
Standard  T1. 602. 


A.2  Signaling 

The  following  table  provides  the  cross-references  between  those  sections  of  CCITT  Recommendation 
Q.931  referenced  in  7.2.5  of  this  document  and  the  corresponding  ANSI  ISDN  Standards. 


Table  1  -  ANSI-CCITT  Cross-References 


CCITT  RECOMMENDATION  Q.931 


ANSI  T1.608 


Section 


2.1 


Section  4.1  (refers  to  sec. 


Section 
Section 


2.2 
3.1 


2.1.1  of  ANSI  T1.607) 
Section  4.2 

Section  5.1  (refers  to  sec. 


Section 
Section 
Section 
Section 
Section 
Section 
Section 
Section 
Section 
Section 
Section 
Section 
Section 
Section 
Section 


3.2 
4.1 
4.2 
4.3 
4.4 
4.5 
4.7 
6 

6.1.1 

6.1.2.2 

6.2.1 

6.2.2.2 

6.4.1 

6.4.2 

6.4.3 


3  of  ANSI  T1.607) 
Section  5.2 
Section  6.1 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Lower  Layers  Special  Interest  Group 
(LLSIG)  of  the  National  Institute  of  Standards  and  Technology  (NIST)  Workshop  for  Implementors  of  Open 
Systems  Interconnection  (OSI).  See  Procedures  Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject.  Significant  technical  changes  from  this  text  as  previously 
given  are  routing  addfiassincj-related.  References  are  made  to  Part  2  in  this  part. 


Annex  A  is  for  information  only. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaddd. 


ii 


Part  3  -  Network  Layer 

NOTE  -  The  term  "Ongoing"  used  in  this  document  refers  to  the  Working  Implementation  Agreements  dated 
December  1990. 

0  Introduction 

This  part  presents  agreennents  for  providing  the  OSI  network  sen/ice.  AJso  contained  here  are  agreements 
on  network  layer  addressing  and  routing. 

1  Scope 

These  agreements  cover  both  connectionless-mode  and  connection-mode  network  sen/ices. 

2  Normative  References 

2.1  CCITT 

[1]       Recommendation  X.213  (Blue  Book,  1988),  Network  Sen/ice  Definition  for  Open  Systems 
Interconnection  for  CCITT  Applications. 

2.2  ISO 

[2]       ISO  8348,  Information  processing  systems  -  Data  communications  -  Network  service  defintion. 

[3]       ISO  8348  Addendum  1 ,  Information  processing  systems  -  Data  communications  -  Network  sen/ice 
definition  -  Addendum  1:  Connectionless-mode  transmission. 

[A]       ISO  8348  Addendum  2,  Information  processing  systems  -  Data  communications  -  Network  sen/ice 
definition  -  Addendum  2:  Network  layer  addressing. 

[5]       ISO  8473,  Information  processing  systems  -  Data  communications  -  Protocol  for  providing  the 
connectionless-mode  network  service. 

[6]       ISO  8648,  Information  processing  systems  -  Open  systems  interconnection  -  Internal  organization 
of  tfie  Network  Layer. 

[7]       ISO  8878,  Information  processing  systems  -  Data  communications  -  Use  ofX.25  to  provide  the  OSI 
connection-mode  network  sen/ice. 

[8]       ISO  8881 ,  Information  processing  systems  -  Data  communications  -  Use  of  the  X.25  packet  level 
protocol  in  local  area  networks. 

[9]       ISO  9542,  Information  processing  systems  -  Telecommunications  and  information  exchange 
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between  systems  -  End  system  to  Intermediate  system  routing  exchange  protocol  for  use  in 
conjunction  with  the  Protocol  for  providing  the  connectionless-mode  sen/ice  (ISO  8473). 

[10]  I  SO/I  EC  9574,  Information  technology  -  Telecommunications  and  information  exchange  between 
systems  -  Provision  of  the  OSI  connection-mode  network  service  by  packet  mode  terminal 
equipment  connected  to  an  integrated  sen/ices  digital  network  (ISDN). 

[11]  I  SO/I  EC  TR  9577,  Information  technology  -  Telecommunications  and  information  exchange  between 
systems  -  Protocol  identification  in  the  network  layer. 

[12]  ISO/IEC  TR  10029,  Information  technology  -  Telecommunications  and  information  exchange 
tyetween  systems  -  Operation  of  an  X.25  interworking  unit. 

[13]  ISO/IEC  10030,  Information  processing  systems  -  Telecommunications  and  information  exchange 
between  systems  -  End  system  routeing  information  exchange  protocol  for  use  in  conjunction  with 
ISO  8878. 


3  Status 

This  version  of  the  agreements  was  completed  in  December  1990. 


4  Errata 

This  clause  may  contain  "Defect  Report"  and  resolutions  material,  and  the  versions  of  implementor 
agreements  to  which  this  material  applies. 

The  following  defects  are  being  progressed  in  ISO: 

a)  ISO  9542,  defect  1,  Parts  1-13. 


5     Connectionless-Mode  Network  Service  (CLNS) 
5.1       ISO  8473 

Subsets  of  the  protocol  are  as  follows: 

a)  Implementations  will  not  transmit  PDUs  encoded  using  the  inactive  subset.  Received  PDUs 
encoded  using  the  inactive  subset  will  be  discarded; 

b)  The  non-segmenting  subset  will  not  be  used.  Implementations  will  not  generate  data  PDUs 
without  a  segmentation  part.  However,  implementations  will  receive  and  correctly  process  PDUs 
which  do  not  contain  the  segmentation  part. 

Mandatory  Functions  of  ISO  3473  are  as  follows: 
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a)  The  lifetime  parameter  sliall  be  used  as  specified  in  ciause  6.4  of  iSO  8473.  Tine  parameter  shaii 
have  an  initial  value  of  at  least  three  times  the  network  span  or  three  times  the  maximum  transit 
delay  (in  units  of  500  milliseconds),  whichever  is  greater; 

b)  The  reassembly  timer  for  an  initial  PDU  at  the  reassembly  point  shall  be  no  greater  than  the 
largest  value  of  all  lifetime  parameters  contained  in  all  derived  PDUs; 

c)  The  use/non-use  of  checksums  shall  be  capable  of  being  configured.  The  default  setting  shall 
be  non-use; 

d)  If  the  implementation  supports  the  generation  of  an  ER  PDU,  the  system  shall  insert  in  the 
destination  address  field  of  the  ER  PDU  the  contents  of  the  source  address  field  of  the  PDU  that 
generated  the  error; 

e)  For  the  purposes  of  relaying  and  routing,  a  protocol  entity  need  not  verify  the  correctness  of  ISO 
8348/Add.  2  semantics  carried  in  NPAI  of  received  PDUs. 

Optional  Functions  of  ISO  8473  are  as  follows: 

a)  The  Security  parameter  is  not  defined  by  these  Agreements.  Implementations  shall  not  transmit 
the  parameter  except  where  defined  by  bilateral  agreements; 

b)  Partial  and  complete  source  routing  will  not  be  supported;^ 

c)  Partial  record  of  route  will  bo  supported  by  Intormodiato  GyGtomo; 

d)  ISO  8473  will  be  followed  with  respect  to  QOS; 

e)  For  systems  implementing  the  congestion  notification  function,  the  following  applies: 

1)  A  Globally  Unique  QOS  Maintenance  parameter  shall  be  included  in  all  PDU  originated 
by  End  Systems.  As  specified  in  ISO  8473,  the  initial  value  of  the  Congestion  Experienced 
flag  (CE  flag)  within  the  Globally  Unique  QOS  Maintenance  Parameter  shall  be  set  by  the 
originating  End  System  to  zero.  All  other  flags  within  the  Globally  Unique  QOS  Maintenance 
Parameter  shall  be  set  based  on  the  specific  local  needs  of  the  originating  End  System; 

2)  Intermediate  systems  not  implementing  queue  length  averaging  shall  leave  the  CE  flag 
in  the  same  state  as  it  was  received.  In  particular,  no  intermediate  system  (IS)  shall  ever 
clear  (set  to  zero)  the  CE  flag.  All  intermediate  systems  shall  monitor  all  incoming  and 
outgoing  queues  and  compute  average  queue  lengths  as  shown  by  example  in  figure  1 . 
The  averaging  is  done  from  the  beginning  of  the  previous  cycle  to  the  current  time.  A  cycle 
begins  at  the  instant  of  the  first  NSDU  arrival  after  an  idle  period; 

3)  An  IS  should  set  the  CE  flag  in  all  NSDUs  forwarded  on  a  queue  which  has  an  average 
queue  length  greater  than  one; 


A  defect  exists  with  the  Partial  Source  Routing  option  which  can  cause  PDUs  to  loop  in  the 
network  until  their  lifetime  expires. 
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4)  The  queue  length  averaging  algorithm  computes  the  average  queue  length  over  two 
cycles,  where  the  two  cycles  are: 

a)  the  "previous  cycle",  which  is  the  interval  from  when  the  IS  becomes  busy,  until 
it  t>ecomes  idle  and  the  idle  ends  (indicated  by  the  instant  the  first  packet  arrives 
to  the  idle  IS); 

b)  the  "current  cycle",  which  is  the  interval  from  the  end  of  the  idle  interval  to  the 
current  time  instant  when  the  average  queue  length  is  computed; 

5)  An  embodiment  of  the  averaging  algorithm  is  shown  in  figure  1 ; 

f)  Refer  to  the  Ongoing  Implementation  Agreements  document  for  additional  optional  functions. 


The  algorithm  makes  use  of  the  following  variables: 


t  =  Current  time 

tj  =  time  of  i^"  arrival  or  departure  event 

=  number  of  packets  in  the  system  after  the  event 
Tq  =  time  at  the  beginning  of  the  previous  cycle 
T-j^  =  time  at  the  beginning  of  the  current  cycle 


The  algorithm  consists  of  three  components: 


1.  Queue  Lenath  Update:  Beginning  with  qQ  =  0, 

If  the  i^f^  event  is  an  arrival  event,  q^^  =  q^_2^+l 
If  the  i'-"  event  is  a  departure  event,  q^  =  qj^_3^-l 


2.  Queue  Area  (integral)  update: 


Area  of  the  previous  cycle  =  2  qi-iCt^-t 


tie{To,Ti) 


Area  of  the  current  cycle  -  Z    ^i-1 ( ^i~^i-l ) 


3.  Average  Queue  Length  Update: 


Average  Queue  length  over  the  two  cycles 

Area  of  the  two  cycles      Area  of  the  two  cycles 


Time  of  the  two  cycles 


t-T 


0 


Figure  1  -  Queue  Length  Averaging  Algorithm. 
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The  algorithm  makes  use  o£  the  following  variables: 
t  =  Current  time 

tj^  =  time  of  i^"  arrival  or  departure  event 
qj^  =  number  of  packets  in  the  system  after  the  event 
Tq  =  time  at  the  beginning  of  the  previous  cycle 
T-^  =  time  at  the  beginning  of  the  current  cycle 

The  algorithm  consists  of  three  components: 

1.  Queue  Length  Update:  Beginning  with  qQ  =  0, 

If  the  i^l*  event  is  an  arrival  event,  q^  =  qj^_2^+l 
If  the  i*-"  event  is  a  departure  event,  q^^  =  qj^_j^-l 

2.  Queue  Area  (integral)  update: 

Area  of  the  previous  cycle  =  E  ) 

ti£{To,Ti) 

Area  of  the  current  cycle  =  Z    q^^  l(*^i~*^i-l) 

3.  Average  Queue  Length  Update: 

Average  Queue  length  over  the  two  cycles 

Area  of  the  two  cycles      Area  of  the  two  cycles 


Time  of  the  two  cycles  t-^Q 


Figure  1  -  Queue  Length  Averaging  Algorithm. 

5.2      Provision  of  CLNS  over  Local  Area  Networl<s  (LANS) 

When  providing  CLNS  over  a  LAN  subnetwork,  the  following  shall  apply: 

a)  The  definition  of  CLNS  shall  be  as  specified  in  ISO  8348/Add.  1; 

b)  The  protocol  used  to  provide  CLNS  shall  be  ISO  8473  with  agreements  as  specified  in  5.1; 

c)  The  necessary  subnetwork  dependent  convergence  function  shall  be  as  defined  in  ISO  8473 
Clause  Br&A-  8,4.2,  SNDCF  used  with  ISO  8802/2  sub-networks". 
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5.3  Provision  of  CLNS  over  X.25  Subnetworks 

When  providing  CLNS  over  X.25  subnetworks,  the  following  shall  apply: 

a)  The  definition  of  CLNS  shall  be  as  specified  in  ISO  8348/Add.  1 ; 

b)  The  protocol  used  to  provide  CLNS  shall  be  ISO  8473  with  agreements  as  specified  in  5.1; 

c)  The  necessary  subnetwork  dependent  convergence  function  shall  be  as  defined  in  ISO  8473  - 
clause  &t&t2  8^4,3,  "SNDCF  used  with  ISO  8208  subnetworks  for  operation  over  X.25  subnetworks", 
and  the  default  throughput  class  shall  be  used  if  this  facility  is  available; 

d)  The  X.25  PLP  shall  be  as  specified  in  part  2  clause  6.3. 

5.4  Provision  of  CLNS  over  ISDN 

When  providing  CLNS  over  an  ISDN,  the  following  shall  apply: 

a)  The  definition  of  CLNS  shall  be  as  specified  in  ISO  8348/Add.  1; 

b)  The  protocol  used  to  provide  CLNS  shall  be  ISO  8473  with  agreements  as  specified  in  5.1; 

c)  The  necessary  Sub-network  Dependent  Convergence  function  shall  be  as  defined  in: 

1)  ISO  8473  for  operation  of  CLNP  over  X.25  with  agreements  as  specified  in  5.3; 

2)  ISO  9574  for  control  of  the  B  and  D  channels; 

3)  The  X.25  PLP  shall  be  as  specified  in  part  2,  clause  6.3; 

4)  The  agreements  for  the  ISDN-related  protocols  are  specified  in  part  2,  clause  7. 

NOTE  -  The  stated  scope  of  ISO  9574  does  not  explicitly  cover  the  operation  of  CLNP  over  an  ISDN. 
However,  the  procedure  identified  for  operating  X.25  in  conjunction  w/ith  1.451  is  still  applicable.  The  procedures 
in  ISO  9574  that  correspond  to  8878  are  not  utilized  w/hen  providing  CLNS. 
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5.5      Provision  of  CLNS  over  Point-to-Point  Links 

(Refer  to  the  Ongoing  Implementation  Agreements  document). 

6    Connection-Mode  Network  Service  (CONS) 

The  following  agreements  concern  provision  of  the  connection-mode  Network  Service. 

6.1      Mandatory  Method  of  Providing  CONS 

6.1.1  General 

Independent  of  the  subnetwork  type  (of  part  2),  when  providing  the  CONS  using  X.25-1984,  the  following 
shall  apply  as  described  below: 

a)  The  definition  of  the  CONS  Is  as  specified  in  ISO  8348,  Network  Service  Definition: 

b)  The  mapping  of  the  elements  of  the  CONS  to  the  elements  of  the  X.25  Packet 
Layer  Protocol  (PLP)  is  as  specified  in  6.3.1; 

c)  The  general  procedures  and  formats  of  the  X.25  PLP  are  as  specified  in  ISO  8208, 
X.25  Packet  Layer  Protocol  for  Data  Terminal  Equipment. 

6.1.2  X.25  WAN 

No  provisions  additional  to  those  In  6.1.1  apply  in  an  X.25  WAN. 

6.1.3  LMls 

When  providing  the  CONS  in  a  Local  Area  Network,  the  following  aspects  of  ISO  8881,  in  addition  to  the 
documents  listed  in  6.1.1,  shall  apply: 

a)  Clauses  1-6  and  9-11  for  LLC  Type  1  operation,  including  the  additional 
nonstandard  default  packet  size  listed  in  Clause  6.3,  Note  2. 

NOTE  -  Operation  of  ISO  8208  in  conjunction  with  LLC  Type  2  requires  agreement  on  LLC  Type  2 
procedures. 
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6.1.4  ISDN 

When  providing  the  CONS  in  an  ISDN,  the  considerations  for  control  of  a  B  and  D  channel  in  ISO  9574, 
in  addition  to  those  provided  in  6.1.1,  shall  apply. 

6.2      Additional  Option:  Provision  of  CONS  over  X.25  1980 
Subnetworks 

When  providing  CONS  over  an  X.25  1980  subnetwork,  the  following  shall  apply: 

a)  The  definition  of  the  CONS  is  as  specified  in  ISO  8348,  Netv^ork  Service  Definition: 

b)  The  subnetwork  dependent  convergence  protocol  required  to  provide  CONS  shall 
be  as  specified  in  ISO  8878  Annex  A,  and  referred  to  as  the  Alternative  Procedures  for 
Network  Connection  Establishment  and  Release,  with  agreements  as  defined  in  6.3.2. 


6.3      Agreements  on  Protocols 


6.3.1        ISO  8878 

ISO  8878  Clauses  1-1 1  shall  apply  with  the  following  exception: 

a)  Where  the  ISO  8208  diagnostic  codes  are  not  provided,  all  Cause/Diagnostic 
code  combinations  can  be  mapped  to  the  Originator/Reason  code  of  "Undefined". 


6.3.2       Subnetwork  Dependent  Convergence  Protocol  (ISO  8878/Annex  A) 

The  Receipt  Confirmation  service  will  not  be  provided,  so  the  corresponding  protocol  elements  need  not 
be  implemented. 

The  Expedited  Data  sen/ice  will  not  be  provided,  so  the  corresponding  protocol  elements  need  not  be 
implemented. 


6.4  Interworking 

Interworking  between  subnetworks  whose  End  Systems  use  ISO  8208  to  provide  the  CONS  as  specified 
in  6.1  shall  be  performed  as  specified  in  ISO  TR  10029.  That  is,  an  Intermediate  System  connecting  two 
such  subnetworks  shall  operate  ISO  8208  on  both  subnetworks  and  shall  relay  information  from  one 
subnetwork  to  the  other  as  described  in  ISO  TR  10029. 
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7  Addressing 

NSAP  address  formats  supported  will  conform  to  Addendum  2  of  ISO  8348  as  follows: 

a)  NSAP  address  formats  will  have  a  hierarchical  structure.  This  will  reduce  the  size  of  routing 
tables; 

b)  If  used  in  the  Domain  Specific  Part  (DSP),  an  NSAP  selector  shall  be  the  least  significant 
component  in  the  hierarchy,  and  shall  be  encoded  as  the  last  octet  of  the  DSP.  The  NSAP 
selector  shall  not  be  used  to  perform  routing;  it  is  simply  intended  to  identify  the  network  service 
user  at  the  destination  end  system.  For  those  implementations  using  an  NSAP  selector,  there 
shall  be  one  and  only  one  selector  for  each  NSAP  within  the  end  system.  All  NSAP  addresses 
identifying  a  given  NSAP  will  use  the  same  NSAP  selector  value. 


c)  In  routlnq  erwlronm^ts 

in  which  $ystems  support  NSAP  addresses  containing 

specters  as  specified 

in 

b). 

ttie  corresponding  Network  Entity  Titles  shall  have  the  same 

fonmat  with  the  NSAP 

selector  set  to  zero. 

NOTE  »  This  may  be  incompatible  wth  syslmis  imf^tem^ntecl  accorcttng  to  previous  versions  of  these 


8  Routing 

The  basic  principles  of  Network  Layer  routing  are  defined  in  the  OSI  Routing  Framework  ISO/IEC  TR 
9575.  These  principles  state  that: 

a)  The  global  OSI  environment  will  consist  of  a  number  of  Administrative  Domains,  An 
Administrative  Domain  consists  of  a  collection  of  End  Systems  (ESs)  and  Intermediate  Systems 
(ISs),  and  subnetworks  operated  by  a  single  organization  or  Administrative  Authority.  The 
Administrative  Authority  is  responsible  for:  the  organization  of  ESs  and  ISs  into  Routing 
Domains;  the  assignments  of  NSAP  and  SNPA  addresses;  the  policies  that  govern  resource 
usage;  the  policies  that  govern  the  information  that  is  collected  and  disseminated  both  internally 
and  externally  to  the  Administrative  Domain;  and  the  establishment  of  subdomains  and  the 
corresponding  delegation  of  responsibilities; 

b)  A  Routing  Domain  is  a  set  of  ESs  and  ISs  which  operate  according  to  the  same  routing 
procedures  and  which  is  wholly  contained  within  a  single  Administrative  Domain.  An 
Administrative  Authority  may  delegate  to  the  entity  responsible  for  a  Routing  Domain  the 
responsibilities  to  further  structure  and  assign  NSAP  and  SNPA  addresses.  The  hierarchical 
decomposition  of  Routing  Domains  into  subdomains  may  greatly  reduce  the  resources  required 
in  the  maintenance,  computation,  and  storage  of  routing  information; 

c)  The  OSI  routing  problem,  and  consequently  OSI  routing  protocols,  has  been  decomposed 
into  three  distinct  classes: 
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1) 


End  System  (ES)  to  Intermediate  System  (IS)  routing  within  a  single  subnetwork; 


2) 


IS  to  IS  routing  within  a  single  routing  domain  (Intra-domain); 


3) 


IS  to  IS  routing  between  routing  domains  (Inter-domain). 


8.1      ISO  9542  End  System  to  Intermediate  System  Routing 

For  use  in  conjunction  with  ISO  8473  over  LANs  (refer  to  part  2,  clause  5)  and  point-to-point  links,  ISO 
9542  shall  be  used  to  provide  the  routing  exchange  protocol. 

Additionally,  a  management  mechanism  capable  of  adding  and  deleting  entries  into  the  Routing 
Information  Base  (RIB)  is  recommended.  When  using  the  management  mechanism  to  add  an  entry, 
there  should  be  no  holding  timer,  and  the  entry  should  be  write  protected  from  alteration  by  the  ES-IS 
protocol.  This  mechanism  enables  routing  table  entries  to  be  made  which  are  static  in  nature. 

The  agreements  below  apply  to  the  use  of  ISO  9542: 

a)  Implementors  shall  support  any  valid  NSAP  format.  For  the  purposes  of  the  protocol,  NSAP 
addresses  are  treated  simply  as  octet  strings; 

b)  For  LANs,  implementors  shall  support  both  Configuration  Information  and  Route  Redirection 
Information;  no  subsets  are  permitted; 

c)  All  timer  values  shall  be  configurable; 

d)  Use  or  non-use  of  checksums  shall  be  configurable.  It  is  recommended  not  to  use  ISO  9542 
checksums  when  originating  PDUs; 

e)  The  QOS,  Security  and  Priority  parameters  should  not  be  used  for  routing.  For  conformance, 
intermediate  systems  must  transmit  these  parameters  in  RD  PDUs  if  they  are  present  in  the  data 
PDU  which  generated  the  redirect.  However,  end  systems  must  ignore  them  in  received  RD 
PDUs; 

f)  If  the  configuration  notification  function  described  in  6.7  of  the  protocol  specification  is 
implemented,  a  mechanism  shall  be  provided  to  enable/disable  this  function  on  broadcast 
networks.  If  supported  in  end  systems  listening  to  both  ISHs  and  ESHs,  this  function  shall  only 
be  invoked  upon  receipt  of  an  ISH.  Alternate  mechanisms  for  ISs  and  ESs  are  described  in  8.1.1 
and  8.1.2. 

g)  For  LANs,  this  protocol  employs  the  same  LSAP  as  ISO  8473; 
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h)  The  encoding  of  the  BSNPA  address  follows  the  syntax  rules  for  the  data  link  being  used.  On 
a  LAN,  for  example,  it  is  a  48-bit  MAC  address  encoded  as  specified  in  clause  12.2.1.4  of  ISO 
10039; 

i)  The  multicast  addresses  corresponding  to  "All  Intermediate  Systems  on  the  Network" 
(ALLJSN)  and  "All  End  Systems  on  the  Network"  (ALL_ESN)  shall  default  to  the  following  on 
IEEE802.3  and  IEEE802.4  subnetworks: 

1)  ALL_ESN  =  09-00-2B-00-00-04,  ALLJSN  =  09-00-2B-00-00-05; 

2)  It  is  understood  that  the  hexadecimal  octets  shown  are  transmitted  onto  the  medium 
from  left  most  octet  to  right  most  octet.  Within  each  hexadecimal  octet  the  least 
significant  bit  is  transmitted  first; 

j)  The  multicast  addresses  corresponding  to  "All  Intermediate  Systems  on  the  Network" 
(ALLJSN)  and  "All  End  Systems  on  the  Network"  (ALL_ESN)  shall  default  to  the  following  two 
functional  addresses  on  IEEE802.5  subnetworks: 

1)  ALL_ESN  =  COOO  0000  4000,  ALLJSN  -  COOO  0000  8000; 

2)  It  is  understood  that  the  hexadecimal  octets  shown  are  transmitted  onto  the  medium 
from  left  most  octet  to  right  most  octet.  Within  each  hexadecimal  octet  the  most 
significant  bit  is  transmitted  first; 


Editor's  Note  -  Note  that  in  the  hexadecimal  representation  defined  in  ISO  10039,  these  addresses  would 
be: 

1)  ALL_ESN  =  03-00-00-00-02-00 

2)  ALLJSN  =  03-00-00-00-01-00 


NOTE  -  This  notation  presents  the  octet  values  such  that  the  least  significant  bit  is  that  transmitted  first. 

k)  The  Error  Report  flag  shall  be  set  to  zero  (0)  for  NPDUs  sent  as  a  result  of  invoking  the 
QUERY  Configuration  Function. 

I)  ISO  8473  PDUs  multicast  as  a  result  of  the  Query  Configuration  function  shall  use  the 
Network  Layer  Protocol  ID  (NLPID)  assigned  to  ISO  8473. 

m)  An  ISO  8473  PDU  received  as  a  result  of  another  ES  having  performed  the  Query 
Configuration  function  shall  be  processed  as  follows: 

1)  If  the  ISO  8473  PDU  is  addressed  to  one  of  the  NSAPs  present  in  the  ES,  the  End 
System  shall  process  the  PDU  according  to  the  applicable  clauses  of  ISO  8473  and 
Invoke  the  Configuration  Response  Function  (clause  6.6  of  ISO  9542); 

2)  If  the  ISO  8473  PDU  is  not  addressed  to  one  of  the  NSAPs  present  in  the  ES,  the 
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End  System  shall  discard  the  PDU  without  generating  an  ISO  8473  Error  Report; 

n)  For  purposes  of  address  matching  and  SNPA  extraction,  the  first  octet  of  the  option 
parameter  value  of  an  address  (clause  7.4.5)  or  SNPA  Mask  (clause  7.4.6)  shall  be  aligned  with 
the  first  octet  (API)  of  the  encoded  trial  NSAP  Address. 

The  following  Items  represent  proposed  solutions  to  defects  in  ISO  9542.  These  solutions  are  being 
progressed  as  defect  reports  to  ISO  9542.  These  Items  will  be  deleted  when  the  corresponding  defect 
report  Is  approved: 

a)  An  End  System  may  choose  to  ignore  an  RD  PDU  received  for  a  destination  to  which  the  ES 
has  not  sent  traffic  for  some  period  of  time.  An  ES  must  record  redirection  information  only  for 
those  other  systems  with  which  it  Is  in  active  communication; 

b)  A  holding  time  value  of  zero  is  permitted.  When  configuration  and/or  redirection  information 
with  a  zero  holding  time  Is  received,  prior  Information  shall  be  replaced,  thus  causing  the  system 
to  set  Its  holding  timer  to  zero  and  discard  the  corresponding  Information; 

c)  If  one  or  more  ISs  suggested  an  ESCT,  the  minimum  of  the  non-zero  suggested  values 
replaces  the  current  value  of  the  ES's  CT. 


8.1 .1       Alternative  Configuration  Mechanism  -  IS  Actions 

An  alternative  mechanism  for  achieving  rapid  configuration  which  is  scaleable  to  large  broadcast 
networks  Is  described  below.  This  mechanism  makes  use  of  the  Suggested  ES  Configuration  Timer. 
Implementation  of  this  mechanism  is  optional. 

When  an  Intermediate  system  wants  to  quickly  acquire  the  End  system  configuration  (for  example,  when 
a  broadcast  circuit  is  enabled  on  the  IS  or  the  topology  changes  because  of  a  failure  of  a  bridge  or 
repeater),  it  initiates  a  "poll"  of  the  End  system  configuration  by  performing  the  following  actions: 

a)  Delay  a  random  interval  between  0  and  PollESHelloRate  seconds.  (This  is  to  avoid 
synchronization  with  other  ISs  which  have  detected  a  change.); 

b)  In  order  to  rapidly  time  out  any  End  systems  which  are  no  longer  present  on  the  broadcast 
circuit  (for  example,  after  a  LAN  partition),  reset  the  entryRemainingTlme  in  the  Routing 
Information  Base  for  all  End  systems  on  this  circuit  to  the  value:  (ISHelloTimer  + 
PollESHelloRate)  *  HoldingMultlplier  or  the  existing  value  whichever  is  lowest.  Where 
ISHelloTimer  Is  the  Intermediate  system's  configuration  timer,  HoldingMultlplier  is  a  predefined 
number  (for  example,  2)  which  multiplied  by  ISHelloTimer  gives  the  value  for  the  Holding  Time 
field  of  IS  Helios; 

c)  Then  transmit  HoldingMultlplier  IS  Helios  with  a  Suggested  ES  Configuration  Timer  value  of 
PollESHelloRate  seconds  with  an  inten/al  of  ISHelloTimer  seconds  between  each  and  setting  the 
Holding  Time  field  to  ISHelloTimer  *  HoldingMultlplier; 

d)  Then  start  sending  IS  Helios  with  a  Suggested  ES  Configuration  Timer  of  DefaultESHelloRate 
seconds  (where  DefaultESHelloRate  Is  larger  than  PollESHelloRate). 
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8.1.2       Alternate  Configuration  Mechanism  -  ES  Actions 

An  End  system  maintains  for  each  circuit  a  list  (CTList)  wfiich  has  HoldingMultiplier  elements  each  of 
which  stores  a  received  value  of  the  Suggested  ES  Configuration  Timer.  The  function  SaveCT(t)  adds  the 
value  t  as  the  first  element  of  CTList  and  discards  the  last  element.  The  function  MinCT  delivers  the 
minimum  value  in  CTList.  When  the  circuit  is  enabled  all  the  elements  of  CTList  are  initialized  to 
PollESHelloRate. 

An  End  system  also  maintains  for  each  circuit  the  variables  currentSuggestedHelloTimer  and  its 
associated  lifetime  currentSuggestedHelloTimerLifetime.  These  are  both  initialized  to  PollESHelloRate. 

When  the  circuit  is  enabled  the  Configuration  Timer  is  started  by  setting  the  entryRemainingTime  to 
random  (PollESHelloRate). 

On  Configuration  Timer  expiry  the  following  actions  are  performed: 

a)  SaveCT (currentSuggestedHelloTimer); 

b)  Transmit  an  ES  Hello  with  Holding  Time  field  set  to  MinCT  *  HoldingMultiplier; 

c)  Set  entryRemainingTime  to  MinCT  -  random(MinCT  *  0.25).  (The  random  element  ensures 
that  End  systems  do  not  become  synchronized.) 

When  an  End  system  receives  an  IS  Hello  which  contains  a  Suggested  ES  Configuration  Timer,  it  is 
processed  as  follows  (where  suggestedESCT  is  the  value  contained  in  the  option): 

a)  If  suggestedESCT  is  less  than  or  equal  to  currentSuggestedHelloTimer  then  set 
curentSuggestedHelloTimerLifetime  to  the  value  of  the  Holding  Time  field  of  the  IS  Hello; 

b)  If  suggestedESCT  is  less  than  currentSuggestedHelloTimer  then  set 

currentSuggestedHelloTimer  to  suggestedESCT  and  reset  entryRemainingTime  to  the  smaller  of 
its  current  value  and  random(currentSuggestedHelloTimer  *  0.75). 

When  the  currentSuggestedHelloTimerLifetime  expires,  set  the  currentSuggestedHelloTimer  to 
DefaultESHelloTimer. 


8.2      ISO  10030  End  System  to  Intermediate  System  Routing 

The  protocol  used  to  provide  End  System  to  Intermediate  System  routing  in  support  of  the  CONS  (refer 
to  3.6)  shall  be  ISO  10030. 

The  following  agreements  apply  to  the  use  of  ISO  10030: 

a)  A  management  mechanism  capable  of  adding  and  deleting  entries  in  the  Routing  Information 
Base  (RIB)  of  both  SNAREs  and  End  Systems  is  recommended.  When  using  the  management 
mechanism  to  add  an  entry  it  should  not  be  timed  out,  and  the  entry  should  be  write  protected 
from  alteration  by  the  ISO  10030  protocol. 
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h)  Thfif  fmilSc^  a<ldr6$$6$  fiOftespondlng  to  *M  OOMS  End  ^ysieras"  and  '^All  CONS  mmE^'' 
shad  de^ult  to  Ibe  following  on  IEEE  80^.3  and  JEEE  S02:^4  suljnelworkK 

1>  Ail  CONS  End  Systems  01-80<:a-00^»16 

Z)  M  com  SNARE:      -  O1^^2h00HDD*17 

8.3  Intra-Domain  Intermediate  Systems  to  Intermediate  Systems 
Routing 

Intermediate  systems  shall  provide  mechanisms  to  create  and  update  the  required  Routing  Information 
Base. 

8.4  Inter-Domain  Intermediate  Systems  to  Intermediate  Systems 
Routing 

An  Administrative  Authority  shall  determine  the  procedures  and  policies  that  govern  the  exchange  of 
routing  information  with  other  routing  domains. 

Intermediate  systems  shall  provide  management  mechanisms  to  configure  the  required  inter-domain 
routing  information. 

9     Procedures  for  OSI  Network  Service/Protocol  Identification 
9.1  General 

The  Protocol  Identifiers  specified  in  ISO  TR  9577  ("Protocol  Identification  in  the  OSI  Network  Layer") 
provide  a  basis  from  which  OSI  systems  (both  end  systems  and  intermediate  systems)  may  derive  a  set 
of  procedures  for  indicating  which  OSI  protocols  are  used  in  a  particular  instance  of  communication.  As 
such,  these  procedures  are  only  concerned  with  Initial  Protocol  Identifiers  (IPIs)  and  Subsequent 
Protocol  Identifiers  (SPIs)  that  identify  OSI  protocols  and  pertain  to  the  following  types  of  systems: 

a)  systems  providing/supporting  only  CONS  (using  ISO  8208/8878); 

b)  systems  providing/supporting  only  CLNS  (using  ISO  8473); 

c)  systems  providing/supporting  both  CONS  and  CLNS. 

From  this  set  of  definitions,  the  following  possibilities  for  success  (S)  or  failure  (F)  of  an  instance  of 
communication  can  be  defined,  as  shown  in  the  table  below: 
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Table  1  -  End  Systems  Communications 


Originating 

Destination 

End 

System  Type 

End  System  Type 

A 

B 

C 

A 

S 

F 

S 

B 

F 

S 

S 

C 

S 

S 

S 

9.2      Processing  of  Protocol  Identifiers 

The  usage  of  Protocol  Identifiers  in  Network  Protocol  Data  Units  (NPDUs)  depends  on  several  factors: 

a)  the  OSI  Network  Service  to  be  provided; 

b)  the  protocol  to  be  used  in  providing  this  service; 

c)  the  role  the  protocol  is  to  be  used  in  (per  the  Internal  Organization  of  the  Network 
Layer); 

d)  the  type  of  subnetwork  to  which  the  system  is  connected. 


9.2.1       Originating  NPDUs 

The  use  of  a  particular  OSI  Network  Service  depends  on  the  capabilities  of  both  the  origination  and 
destination  end  systems.  It  is  not  the  intent  of  this  clause  to  provide  guidelines  on  how  to  make  this 
choice  except  for  simple  obvious  criteria;  rather,  it  is  intended  only  to  provide  guidance  on  how  to 
convey  this  choice  to  the  destination  system. 

Where  a  priori  knowledge  exists  in  the  originating  end  system  about  the  capabilities  (with  respect  to  OSI 
Network  Services  available)  of  the  destination  end  system,  it  should  be  used.  This  may  result  in  no 
communication  if  the  two  end  systems  involved  only  provide  Network  Services  of  different  types.  A 
selection  is  required  in  cases  where  both  end  systems  provide  both  types  of  network  sen/ices;  this 
selection  is  conveyed  by  the  use  of  the  I  PI  and  SPI  (but  the  selection  process  is  an  implementation 
matter).  Alternatively,  where  a  priori  knowledge  does  not  exist,  then  the  selection  of  a  sen/ice  to  use  in 
an  instance  of  communication  depends  solely  on  the  capabilities  of  the  originating  end  system  as 
described  below: 

a)  If  only  CONS-related  protocols  (e.g.,  ISO  8208)  are  available,  then  this  should  be 
used  and  the  Protocol  Identifiers  specified  so  as  to  reflect  the  chosen  protocol (s)  and 
service; 
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b)  If  only  CLNS-related  protocols  (e.g.,  ISO  8473)  are  available,  then  this  should  be 
used  and  the  Protocol  Identifiers  specified  so  as  to  reflect  the  chosen  protocol (s)  and 
service; 

c)  If  both  services  are  available,  then  other  criteria  are  used  in  deciding  which  to  use 
in  an  instance  of  communication. 

NOTE  -  The  choice  of  OSI  Network  Service  to  be  used  in  an  instance  of  communication  is  reflected  in  the 
Network  Service  primitives  issued  by  the  Network  Service  user. 

Once  a  selection  of  Network  Service  has  been  made,  the  use  of  particular  protocols  depend  on,  for 
example,  the  subnetwork  to  which  the  originating  End  System  is  attached.  Some  specific  cases  are 
given  in  Annex  A  of  ISO  TR  9577.  Another  case  involves  use  of  the  Protocol  for  Providing  the 
Connectionless  Network  Service  directly  over  the  Data  Link  Sen/ice,  as  given  in  ISO  8473  (e.g.,  in  a 
LAN).  In  this  case,  the  IPI  indicates  ISO  8473. 


9.2.2       Destination  System  Processing 

A  system  receiving  an  NPDU  must  first  be  concerned  with  the  protocol  identified  by  the  IPI.  Valid  values 
are  given  in  table  2  of  ISO  TR  9577.  If  the  protocol  is  recognized  as  one  supported  by  the  system, 
further  processing  of  the  protocol  is  performed  according  to  the  rules  of  that  protocol.  If  not,  an  error 
is  recognized  and  may  be  conveyed  to  the  originating  peer  entity.  With  respect  to  ISO  8208  and  ISO 
8473,  the  following  would  apply  for  such  error  conditions: 

a)  For  ISO  8208,  the  condition  is  classified  as  an  "invalid  General  Format  Identifier", 
for  which  a  DIAGNOSTIC  packet  may  be  returned.  If  DIAGNOSTIC  packets  are  not 
used  by  the  system,  the  NPDU  is  discarded  without  any  further  action; 

b)  For  ISO  8473,  the  NPDU  is  discarded  without  any  further  action. 

Given  acceptance  of  the  protocol  identified  by  the  IPI,  the  system  must  also  determine  the  acceptability 
of  the  subsequent  protocols  and  OSI  Network  Service  being  requested.  Use  of  ISO  8473  implies  CLNS; 
however,  use  of  ISO  8208  can  imply  either  CONS  or  CLNS,  as  identified  by  the  SPI.  In  the  case  of  ISO 
8208,  therefore,  further  processing  is  needed  to  determine  the  acceptability  of  the  requested 
protocol/service.  If  these  are  not  acceptable  (e.g.,  not  supported  by  the  system),  the  call  should  be 
cleared  with  a  diagnostic  code  of  "Connection  Rejection  -  unrecognizable  protocol  identifier  in  user 
data"  (decimal  249). 

NOTE  -  In  ISO  8208,  a  call  may  be  refused  for  reasons  other  than  non-support  of  the  requested  OSI 
Network  Service. 
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Further  processing  on  receipt  of  an  NPDU  in  response  to  an  initial  attempt  to  communicate  may  be 
necessary/useful  to  determine  the  success  of  such  an  attempt. 

For  ISO  8473,  when  used  directly  over  the  Data  Link  Service,  the  success  or  failure  of  an  attempt  to 
communicate  may  not  t>e  visible/obvious  within  the  Network  Layer.  On  the  other  hand,  use  of  ISO  8473 
over  ISO  8208  may  provide,  via  the  diagnostic  code  in  a  received  CLEAR  INDICATION  packet,  an 
indication  of  failure  to  communicate  (e.g.,  the  remote  system  does  not  support  CLNS). 

When  using  ISO  8208  to  provide  the  CONS,  the  diagnostic  code  in  a  received  CLEAR  INDICATION 
packet  may  provide  the  necessary  indication  of  why  a  call  was  refused. In  cases  where  an  ISO  8208  call 
is  refused  with  diagnostic  #249,  it  would  not  be  desirable  to  re-attempt  such  calls  with  the  exact  same 
set  of  parameters;  however,  how  the  originating  system  ensures  this  is  a  local  matter. 

In  cases  where  an  originating  system  is  capable  of  supporting  both  OSI  Network  Services,  it  may  wish 
to  re-attempt  communications  using  the  other  mode  of  Network  Service  than  that  initially  attempted. 


9.3      Applicable  Protocol  Identifiers 

The  protocol  identifiers  applicable  to  these  agreements  are  given  in  table  2  and  table  3. 


Table  2  -  IPI  Values 


Bit  Pattern 
87654321 

Protocol 

00001000 
10000001 
10000010 
xxOlxxxx 
xxlOxxxx 
OOllxxxx 

CCITT  I.451/Q.931 

ISO  8473  (excluding  the 

inactive  subset) 

ISO  9542 

ISO  8208/CCITT  X.25-Modulo  8 
ISO  8208/CCITT  X.25-Modulo  128 
ISO  8208/CCITT  X.25-GFI  Extension 
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Table  3  -  SPI  Values 


Bit  Pattern^ 
87654321 

Protocol 

00000000 
thru 

00111111 

10000001 
10000100 

ISO  8073  ADDl/CCITT  X.224 
See  table  4.1 

ISO  8473 

ISO  8878/Annex  A 

NOTES 

1    A  null  SPI  value  (e.g.,  no  Call  User  Data  Field  in  an 
ISO  8208/CCITT  X.25  Call  Request/Incoming  Call  packet) 
shall  indicate  ISO  8073/CCITT  X.224. 

When  using  ISO  8208,  values  other  than  one  of  those  listed  In  table  3  are  outside  the  scope  of  these 
agreements. 


10  Migration  Considerations 

This  clause  considers  problems  arising  from  evolving  OSI  standards  and  Implementations  based  on 
earlier  versions  of  OSI  standards. 

Until  there  Is  widespread  availability  of  1984  X.25  service,  it  will  be  necessary  for  X.400  systems  to  use 
those  existing  packet-switched  public  data  networks  which  offer  only  pre-1984  X.25  service.  While  1980 
X.25  does  not  provide  the  CONS  as  defined  by  ISO  8348,  there  is  no  implication  of  non-conformance  to 
these  Agreements  resulting  therefrom  for  systems  using  1980  X.25  to  interchange  data  at  the  Network 
Layer,  provided  they  conform  in  all  other  respects. 

This  is  an  exception  to  the  Agreements  for  providing  the  OSI  Network  Service,  granted  temporarily  for 
practical  reasons.  This  exception  will  be  removed  when  it  is  deemed  to  be  no  longer  necessary,  in  the 
judgement  of  the  Workshop.  While  this  provision  is  in  effect,  it  provides  an  alternative  method  of  using 
1980  X.25  to  the  provisions  of  6.2. 


1 1    Use  of  Priority 

Refer  to  the  Ongoing  Implementation  Agreements  document. 
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11.1  Introduction 

Refer  to  the  Ongoing  ImpSementation  Agreements  document. 

1 1 .2  Overview 

Refer  to  the  Ongoing  Implementation  Agreements  document. 

12  Conformance 

Refer  to  the  Ongoing  Implementation  Agreements  document. 
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Provide  and  Support  the  OSI  Network  Service  -  Part  2:  Provision  and  Support  of  the  Connection-mode 
Network  Service. 

ISO/IEC  8880-3,  Information  Processing  Systems  -  Data  Communications  -  Protocol  Combinations  to 
Provide  and  Support  the  OSI  Network  Service  -  Part  3:  Provision  and  Support  of  the  Connectionless- 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Lower  Layers  Special  Interest  Group 
(LLSIG)  of  the  National  Institute  of  Standards  and  Technology  (NIST)  Workshop  for  Implementors  of  Open 
Systems  Interconnection  (OSI).  See  Procedures  Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject.  Significant  toohnioal  changes  from  this  text  ao  proviouoly 
given  arc  in  class  4  protocol  (including  rotranomiosion  timer),  and  in  class  0  protocol. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  4  -  Transport 
0  Introduction 

These  agreements  support  the  integration  of  U^Ns,  pacl<et  networks,  and  other  WANs  with  the  smallest 
possible  set  of  mandatory  protocol  sets,  in  accordance  with  the  other  agreements  already  reached.  Nothing 
here  shall  preclude  vendors  from  implementing  protocol  suites  in  addition  to  the  ones  described  in  this 
document. 


1  Scope 

This  chapter  presents  agreements  for  providing  the  OSI  Transport  layer  services  over  both  connection  mode 
and  connectionless  mode  services. 


2     Normative  References 


2.1  CCITT 

{1|      ReconimendatloR  X214  (Blue  Book,  1988),  TransfiOft  Service  Definition  for  Open  Systems 
tntercoan^tton  for  CCfTT  Appiicaffotm, 

|2|      flect3fT)mendatlor»  X^224  (Blue  Book,  1986),  Tmn$poH  Proibco?  Specif ioniton  for  Open  Systems 
tniercomectim  far  CCfTT  Appitcathns. 

(3|      \B0  8072^  fntormatfon  processing  systems  -  Opert  systems  interconnection  -  Transport  sen^fce 
defMmi 

J4|      ISO  8072  Acki^dum  1,  information  processing  systems  -  Open  systems  interconnection  - 
Addendum  1:  Transport  sen/ic&  definition  *  ComQcffoniess-mode  wansmission. 

m      ISO  6073  Edition  2,  information  processing  systems  *  Open  systems  intercomection  *  Connection 
Ortmted  tratisport  protocoi  ^ecification. 


m  i$0  8073  Addendum  1,  tnfonmtion  processing  systems  -  Open  systems  interconnection  - 
Cmnection  oriented  ^nspott  proiooot  speciffcatii}n  -  Addendum  1:  Netwoiit  connection 
msmg:^ei^sttlbpmt0mii 


in 

ISO  BQ7$  Addendum  2,  information  processing  systems  - 

Open 

systems  interconnection 

Connection  oriented  timtsport  protocoi  ^deification  - 

'  Add&ndum  2: 

Class  four 

operation  over 

connectionless  network  sermce> 

{8|      iSO  8602,  information  processing  sy^ems  -  Opei?  systems  imerconnection  -  Protocoi  for  providing 
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3  Status 

Completed  December  1990. 

4  Errata 


NOTE  -  This  clause  may  contain  "defect  report"  and  resolutions  material,  and  the  versions  of  implementor 
agreements  to  which  this  material  applies. 


5     Provision  of  Connection  Mode  Transport  Service 

Three  connection  mode  protocol  classes  have  been  identified  for  implementation.  Transport  classes  0, 2  and 
4  of  X.224  (1988)^  have  been  endorsed  for  use  over  CONS.  Only  Transport  Class  4  of  ISO  8073/Add.  2  ^ 
has  been  endorsed  for  use  over  CLNS.  The  following  class  combinations  are  endorsed  for  CONS:  (0),  (0,2) 
or  (0,2,4). 


5.1      Transport  Class  4 


5.1.1       Transport  Class  4  Overview 

Transport  Class  4  is  mandatory  for  communication  between  systems  using  the  OSI  CLNS  and  may  also  be 
used  for  systems  using  the  OSI  CONS  (e.g.,  a  private  MHS,  etc.). 


Where  a  OR  TPDU  proposing  Class  2  or  4  is  initiated.  Class  0  shall  be  explicitly  indicated  as  an 
alternative  class  except  if  there  is  already  one  (or  several)  transport  connection(s)  assigned  to  the 
network  connection  (multiplexing  being  possible). 


In  general,  references  to  ISO  8073  in  ISO  8073/Add.  2  should  be  interpreted  as  applying  to  X.224 
(1988);  however,  the  reference  to  Clause  14.6.a  in  Clause  14  of  ISO  8073/Add.  2  should  be 
interpreted  as  a  reference  to  Clause  14.5.a  of  X.224(1988). 
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5.1.2       Protocol  Agreements 

A  disconnect  request  shall  be  Issued  In  response  to  a  connect  request  when  the  maximum  number  of 
Transport  connections  is  reached  or  exceeded. 


5.1.2.1         General  Rules 

The  rules  are  as  follows: 

a)  All  Implementations  shall  request  "use  of  extended  formats"  in  the  CR  TPDU.  Implementations 
shall  accept  the  "use  of  extended  formats"  in  the  CC  TPDU  if  it  was  proposed  In  the  CR  TPDU. 
Implementations  shall  accept  "use  of  normal  formats"  if  it  was  proposed  In  the  CR  TPDU; 

b)  Negotiation  of  protection  is  outside  the  scope  of  these  agreements.  If  negotiation  of  protection 
is  not  supported,  receipt  of  the  protection  parameters  In  CR  TPDU  and  CC  TPDU  shall  be  Ignored; 

c)  Implementations  shall  be  capable  of  proposing  and  accepting  the  non-use  of  checksums; 

d)  Use  of  the  acknowledgment  time  parameter  Is  optional.  If  an  implementation  Is  operating  any 
policy  which  delays  the  transmission  of  AK  TPDUs,  the  maximum  amount  of  time  by  which  a  single 
AK  TPDU  may  be  delayed  shall  be  Indicated  to  the  peer  Transport  service  provider  using  the 
acknowledgment  time  parameter.  The  value  transmitted  should  be  expressed  in  units  of  milliseconds 
and  rounded  up  to  the  nearest  whole  millisecond; 

e)  QoS  negotiation  is  outside  the  scope  of  these  agreements.  If  QoS  negotiation  Is  not  supported, 
receipt  of  the  parameters  "throughput",  "residual  error  rate",  "priority",  and  "transit  delay"  in  the  CR 
and  CC  TPDUs  shall  be  ignored; 

f)  It  is  recommended  that  implementations  not  send  user  data  in  the  CR  TPDU  or  the  CC  TPDU. 
The  disposition  of  any  user  data  received  in  a  CR  TPDU  or  CC  TPDU  is  Implementation  dependent; 

g)  It  is  recommended  that  implementations  not  send  user  data  In  the  DR  TPDU.  The  disposition 
of  any  user  data  received  in  a  DR  TPDU  is  implementation  dependent; 

h)  An  unknown  parameter  in  any  received  CR  TPDU  shall  be  Ignored; 

i)  A  Transport  entity  shall  accept  a  DR  TPDU  and  a  corresponding  DC  TPDU  with  or  without  a 
checksum  In  response  to  a  CR  or  CC  TPDU; 
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j)  Transmitted  DR  TPDUs  shall  carry  a  disconnect  reason  code  which  pertains  to  the  actual  cause 
of  the  disconnect.  A  DR  TPDU  may  carry  a  reason  code  of  "0"  (unspecified)  if  an  appropriate  reason 
code  is  not  defined; 

k)  Known  parameters  with  valid  lengths  but  with  invalid  values  in  a  CR  TPDU  shall  be  handled  as 
follows: 

1)  Parameter:  2)  Action: 

a)  TSAP  id  a)  Send  DR  TPDU 

b)  TPDU  size  b)  ignore  parameter,  use  default 

c)  Version  c)  ignore  parameter,  use  default 

d)  Checksum  d)  discard  CR  TPDU 

e)  Alternate  Protocol  Classes    e)  Protocol  Error 

I)  Unrecognized  or  not  applicable  bits  of  the  Additional  Options  parameter  shall  be  ignored. 

m)  It  is  recommended  that  the  capability  of  request  acknowledgments  be  supported  and  proposed 
in  CR  TPDUs.  If  request  acknowledgments  are  supported,  then  if  the  implementation  delays 
acknowledgments  it  shall: 

1)  request  use  of  request  acknowledgments  in  the  CR  TPDU; 

2)  accept  the  use  of  request  acknowledgments  in  the  CC  TPDU  if  It  was  proposed  in  the 
CR  TPDU. 

n)  It  is  recommended  that  implementations  send  both  the  preferred  and  existing  TPDU  size 
parameters  in  the  CR  TPDU. 

o)  It  is  recommended  that  inactivity  timer  values  be  exchanged  during  connection  establishment. 
This  may  be  mandatory  in  the  future.  If  the  "exchange  of  inactivity  timers"  capability  is  supported, 
the  implementation  shall  send  its  minimum  inactivity  timer  in  the  CR  TPDU.  If  a  CR  TPDU  is  received 
,  with  this  timer  value  and  the  capability  is  supported,  the  responding  CC  TPDU  shall  contain  the 
inactivity  time. 

If  the  Inactivity  time  is  received  and  the  capability  is  supported,  the  following  shall  be  used  as  an  upper 
bound  for  w  il: 

(Ir-Elr)/N>W  N>2 
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Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Lower  Layers  Special  Interest 
Group  (LLSIG)  of  the  National  Institute  of  Standards  and  Technology  (NIST)  Workshop  for  Implementors 
of  Open  Systems  Interconnection  (OSI).  See  Procedures  Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This 
part  replaces  the  previously  existing  chapter  on  this  subject.  Significant  technical  changes 
from  this  text  as  previously  given  are  in  class  4  protocol  (including  retransmission  timer),  and 
in  class  0  protocol. 
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Part  4  -  Transport 


0  Introduction 

These  agreements  support  the  integration  of  LANs,  packet  networks,  and  other  WANs  with  the  smallest 
possible  set  of  mandatory  protocol  sets,  in  accordance  with  the  other  agreements  already  reached.  Nothing 
here  shall  preclude  vendors  from  implementing  protocol  suites  in  addition  to  the  ones  described  in  this 
document. 


1  Scope 

This  chapter  presents  agreements  for  providing  the  OSI  Transport  layer  services  over  both  connection  mode 
and  connectionless  mode  services. 


2     Normative  References 


CCITT 

1.  Recommendation  X.214  (Blue  Book,  1988),  Transport  Service  Definition  for  Open  Systems 
Interconnection  for  CCITT  Applications. 

2.  Recommendation  X.224  (Blue  Book,  1988),  Transport  Protocol  Specification  for  Open  Systems 
Interconnection  for  CCITT  Applications. 

ISO 

1 .  ISO  8072,  Information  processing  systems   Open  systems  interconnection  --  Transport  service  defintion. 

2.  ISO  8072  Addendum  1,  Information  processing  systems  --  Open  systems  interconnection  --  Addendum 
1 :  Transport  service  definition  --  Connectionless-mode  transmission. 

3.  ISO  8073  Edition  2,  Information  processing  systems  --  Open  systems  interconnection  --  Connection 
oriented  transport  protocol  specification. 

4.  ISO  8073  Addendum  1,  Information  processing  systems  --  Open  systems  interconnection  --  Connection 
oriented  transport  protocol  specification  --  Addenum  1:  Network  connection  management  subprotocol. 

5.  ISO  8073  Addendum  2,  Information  processing  systems  --  Open  systems  interconnection  --  Connection 
oriented  transport  protocol  specification  --  Addendum  2:  Class  four  operation  over  connectionless  network 
service. 

6.  ISO  8602,  Information  processing  systems  --  Open  systems  interconnection  --  Protocol  for  providing  the 
connectionless-mode  transport  service. 
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3  Status 

Completed  December  1990. 


4  Errata 


NOTE  -  This  clause  may  contain  "defect  report"  and  resolutions  material,  and  the  versions  of  implementor 
agreements  to  which  this  materia!  applies. 


5     Provision  of  Connection  Mode  Transport  Service 

Three  connection  mode  protocol  classes  have  been  identified  for  implementation.  Transport  classes  0,  2 
and  4  of  X.224  (1988)^  have  been  endorsed  for  use  over  CONS.  Only  Transport  Class  4  of  ISO 
8073/Add.  2  ^  has  been  endorsed  for  use  over  CLNS.  The  following  class  combinations  are  endorsed 
for  CONS:  (0),  (0,2)  or  (0,2,4). 


Transport  Class  4  is  mandatory  for  communication  between  systems  using  the  OSI  CLNS  and  may  also 
be  used  for  systems  using  the  OS!  CONS  (e.g.,  a  private  MHS,  etc.). 


Where  a  CR  TPDU  proposing  Class  2  or  4  is  initiated,  Class  0  shall  be  explicitly  indicated  as  an 
alternative  class  except  if  there  is  already  one  (or  several)  transport  connection(s)  assigned  to  the 
network  connection  (multiplexing  being  possible). 


In  general,  references  to  ISO  8073  in  ISO  8073/Add.  2  should  be  interpreted  as  applying  to  X.224 
(1988);  however,  the  reference  to  Clause  14.6.a  in  Clause  14  of  ISO  8073/Add.  2  should  be 
interpreted  as  a  reference  to  Clause  14.5.a  of  X.224(1988). 


5.1 


Transport  Class  4 


5.1.1 


Transport  Class  4  Overview 
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5.1.2       Protocol  Agreements 

A  disconnect  request  shall  be  Issued  In  response  to  a  connect  request  when  the  maximum  number  of 
Transport  connections  is  reached  or  exceeded. 


5.1.2.1         General  Rules 

The  rules  are  as  follows: 

a)  All  implementations  shall  request  "use  of  extended  formats"  in  the  CR  TPDU.  Implementations 
shall  accept  the  "use  of  extended  formats"  in  the  CC  TPDU  if  it  was  proposed  in  the  CR  TPDU. 
Implementations  shall  accept  "use  of  normal  formats"  if  it  was  proposed  in  the  CR  TPDU; 

b)  Negotiation  of  protection  is  outside  the  scope  of  these  agreements.  If  negotiation  of  protection 
is  not  supported,  receipt  of  the  protection  parameters  in  CR  TPDU  and  CC  TPDU  shall  be  ignored; 

c)  Implementations  shall  be  capable  of  proposing  and  accepting  the  non-use  of  checksums; 

d)  Use  of  the  acknowledgment  time  parameter  is  optional.  If  an  implementation  is  operating  any 
policy  which  delays  the  transmission  of  AK  TPDUs,  the  maximum  amount  of  time  by  which  a  single 
AK  TPDU  may  be  delayed  shall  be  indicated  to  the  peer  Transport  service  provider  using  the 
acknowledgment  time  parameter.  The  value  transmitted  should  be  expressed  in  units  of  milliseconds 
and  rounded  up  to  the  nearest  whole  millisecond; 

e)  QoS  negotiation  is  outside  the  scope  of  these  agreements.  If  QoS  negotiation  is  not  supported, 
receipt  of  the  parameters  "throughput",  "residual  error  rate",  "priority",  and  "transit  delay"  in  the  CR 
and  CC  TPDUs  shall  be  ignored; 

f)  It  is  recommended  that  implementations  not  send  user  data  in  the  CR  TPDU  or  the  CC  TPDU. 
The  disposition  of  any  user  data  received  in  a  CR  TPDU  or  CC  TPDU  is  implementation  dependent; 

g)  It  is  recommended  that  implementations  not  send  user  data  in  the  DR  TPDU.  The  disposition 
of  any  user  data  received  in  a  DR  TPDU  is  implementation  dependent; 

h)  An  unknown  parameter  in  any  received  CR  TPDU  shall  be  ignored; 

i)  A  Transport  entity  shall  accept  a  DR  TPDU  and  a  corresponding  DC  TPDU  with  or  without  a 
checksum  in  response  to  a  CR  or  CC  TPDU; 
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j)  Transmitted  DR  TPDUs  shall  carry  a  disconnect  reason  code  which  pertains  to  the  actual  cause 
of  the  disconnect.  A  DR  TPDU  may  carry  a  reason  code  of  "0"  (unspecified)  if  an  appropriate  reason 
code  is  not  defined; 

k)  Known  parameters  with  valid  lengths  but  with  Invalid  values  in  a  CR  TPDU  shall  be  handled  as 
follows: 

1)  Parameter:  2)  Action: 

a)  TSAP  id  a)  Send  DR  TPDU 

b)  TPDU  size  b)  ignore  parameter,  use  default 

c)  Version  c)  ignore  parameter,  use  default 

d)  Checksum  d)  discard  CR  TPDU 

e)  Alternate  Protocol  Classes    e)  Protocol  Error 

I)  Unrecognized  or  not  applicable  bits  of  the  Additional  Options  parameter  shall  be  ignored. 

m)  It  is  recommended  that  the  capability  of  request  acknowledgments  be  supported  and  proposed 
in  CR  TPDUs.  If  request  acknowledgments  are  supported,  then  if  the  implementation  delays 
acknowledgments  it  shall: 

1)  request  use  of  request  acknowledgments  in  the  CR  TPDU; 

2)  accept  the  use  of  request  acknowledgments  in  the  CC  TPDU  if  it  was  proposed  In  the 
CR  TPDU. 

n)  It  is  recommended  that  implementations  send  both  the  preferred  and  existing  TPDU  size 
parameters  in  the  CR  TPDU. 

o)  It  is  recommended  that  inactivity  timer  values  be  exchanged  during  connection  establishment. 
This  may  be  mandatory  in  the  future.  If  the  "exchange  of  inactivity  timers"  capability  is  supported, 
the  implementation  shall  send  its  minimum  inactivity  timer  in  the  CR  TPDU.  If  a  CR  TPDU  is  received 
with  this  timer  value  and  the  capability  is  supported,  the  responding  CC  TPDU  shall  contain  the 
inactivity  time. 

If  the  Inactivity  time  is  received  and  the  capability  is  supported,  the  following  shall  be  used  as  an  upper 
bound  for  w  W: 

(Ir-Eur)/N>W  N>2 
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5.1.2.2        Transport  Class  4  Service  Access  Points  or  Selectors 

If  present,  the  TSAP  Id.  field  In  the  CR  and  CC  TPDUs  shall  be  encoded  as  a  variable  length  field  and 
will  be  interpreted  as  an  octet  string.  The  length  of  the  string  cannot  exceed  32  octets. 


5.1.2.3        Retransmission  Timer 

It  is  recommended  that  the  value  used  for  the  retransmission  timer  be  based  upon  the  round-trip  delay 
experienced  on  a  transport  connection.  The  implementation  should  maintain,  and  continually  update,  an 
estimate  of  the  round-trip  delay  for  the  TC.  From  this  estimate,  a  value  for  the  retransmission  timer  is 
calculated  each  time  it  is  started.  Example  techniques  for  maintaining  the  estimate  and  calculating  the 
retransmission  timer  are  described  below.  Example  1  represents  a  simple  retransmission  strategy  and 
example  2  is  particularly  suitable  for  networks  subject  to  high  traffic  loads. 

Example  1 

The  value  of  the  retransmission  timer  may  be  calculated  according  to  the  following  formula: 
T1  < —  kE  +  AR. 

In  this  formula,  E  is  the  current  estimate  of  the  round-trip  delay  on  the  transport  connection,  AR  is  the 
value  of  the  acknowledgement  time  parameter  received  from  the  remote  transport  service  provider 
during  connection  establishment,  and  k  is  some  locally  administered  factor. 

A  value  for  k  should  be  chosen  to  keep  the  retransmission  timer  sufficiently  small  such  that  lost  TPDUs 
will  be  detected  quickly,  but  not  so  small  that  false  alarms  are  generated  causing  unnecessary 
retransmission. 

The  value  of  E  may  be  calculated  using  an  exponentially  weighted  average  based  upon  regular  sampling 
of  the  interval  between  transmitting  a  TPDU  and  receiving  the  corresponding  acknowledgment.  Samples 
are  taken  by  recording  the  time  of  day  when  a  TPDU  requiring  acknowledgment  is  transmitted  and 
calculating  the  difference  between  this  and  the  time  of  day  when  the  corresponding  acknowledgment  is 
received.  New  samples  are  incorporated  with  the  existing  average  according  to  the  following  formula: 

E  <_  E  +  (1  -  a)(S  -  E). 

In  this  formula,  S  is  the  new  sample  and  a  is  a  parameter  which  can  be  set  to  some  value  between  0 
and  1 .  The  value  chosen  for  a  determines  the  relative  weighting  placed  upon  the  current  estimate  and 
the  new  sample.  A  large  value  of  a  weights  the  old  estimate  more  heavily  causing  it  to  respond  only 
slowly  to  variations  in  the  round-trip  delay.  A  small  value  weights  the  new  sample  more  heavily  causing 

I     a  quick  response  to  variations.  (Note  that  setting  a  to  1  will  effectively  disable  the  algorithm  and  result  in 

j     a  constant  value  for  E,  being  that  of  the  initial  seed.) 

'     If  a  is  set  to  1-2  "  for  some  value  of  n,  the  update  can  be  reduced  to  a  subtract  and  shift  as  shown 
below: 
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E  <—  E  +  2  "  (S  -  E). 

When  sampling,  if  an  AK  TPDU  is  received  wliich  acl<nowledges  multiple  DT  TPDUs,  only  a  single 
sample  should  be  taken  being  the  round-trip  delay  experienced  by  the  most  recently  transmitted  DT 
TPDU.  This  attempts  to  minimize  in  the  sample  any  delay  caused  by  the  remote  transport  service 
provider  withholding  AK  TPDUs. 

Example  2 

As  network  load  increases,  the  variability  of  round-trip  delay  also  increases.  In  environments  where  load 
fluctuates  widely,  it  is  therefore  useful  to  estimate  the  variability  of  round-trip  delay  measurements  and 
use  this  estimate  in  the  calculation  of  retransmission  timer  values.  An  estimate  of  the  variability  of  round- 
trip  delay  measurements  can  be  efficiently  calculated  as  an  exponentially  weighted  average  of  the 
differences  between  round-trip  delay  measurements  and  the  average  round-trip  delay.  This  represents 
the  mean  deviation  of  the  round-trip  delays,  which  is  a  useful  approximation  of  the  standard  deviation 
and  can  be  much  more  efficiently  computed.  The  formula  is 

D  <~D  +  (1  -a)(|S-E|  -D) 

where  D  is  the  estimate  of  variability  in  round-trip  delays.  S,  E,  and  a  are  as  defined  for  the  preceding 
formula.  As  before  the  value  of  a  must  be  between  0  and  1  and  the  choice  of  a  value  of  1  -  2  ^^  allows 
for  efficient  update  of  the  average.  The  value  of  a  for  the  variability  estimation,  though,  does  not  need  to 
be  the  same  as  that  used  for  the  round-trip  delay  estimate.  A  smaller  value  for  a  is  useful  in  the 
variability  estimation  to  cause  a  more  rapid  response  to  changes  in  round-trip  delays.  D  can  then  be 
used  to  calculate  retransmission  timer  values  according  to  the  formula: 

T1  <-  E  +  AR  +  kD 

where  T1  is  the  retransmission  timer  value,  E  is  the  estimated  average  round-trip  delay,  AR  is  the  value 
of  the  acknowledgement  timer  parameter  received  from  the  remote  transport  service  provider  during 
connection  establishment,  and  k  is  a  locally  administered  factor.  Since  D  approximates  the  standard 
deviation  of  the  round-trip  delays,  but  is  greater  than  or  equal  to  the  standard  deviation,  round-trip 
delays  within  k  standard  deviations  of  the  mean  would  be  accounted  for  by  the  retransmission  timer 
value  (e.g.,  k  =  2,  if  round-trip  delays  were  normally  distributed,  would  account  for  95%  of  the 
variability). 

Round-trip  time  measurements  based  on  acknowledgement  of  any  retransmitted  data  should  not  be 
used  to  update  the  round-trip  delay  estimate  or  the  estimate  of  variability.  Such  measurements  are  not 
reliable  since  it  is  ambiguous  which  transmission  of  the  data  is  being  acknowledged. 

One  strategy  for  handling  a  retransmission  timeout  is  to  retransmit  the  PDU  and  reset  the  timer  with  a 
value  that  is  twice  the  previous  value.  In  this  case,  a  new  roundtrip  delay  estimate  and  estimate  of 
variability  should  be  calculated  only  when  an  acknowledgement  of  data  is  received  where  none  of  the 
acknowledged  data  has  been  retransmitted.  This  calculation  uses  the  new  round-trip  delay 
measurement  and  the  last  estimate  before  the  retransmission  timeout(s). 
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5.1.2.4        Keep-Alive  Function 

The  Class  4  protocol  detects  a  failed  Transport  connection  by  use  of  an  'Inactivity  timer'.  This  timer  is 
reset  each  time  a  TPDU  is  received  on  a  connection.  If  the  timer  ever  expires,  the  connection  is 
terminated. 

The  Class  4  protocol  maintains  an  idle  connection  by  periodically  transmitting  an  AK  TPDU  upon 
expiration  of  the  'window  timer'.  Thus,  in  a  simple  implementation,  the  interval  of  one  transport  entity's 
window  timer  must  be  less  than  that  of  its  peer's  inactivity  timer,  and  vice  versa.  The  following 
agreements  permit  communicating  transport  entities  to  maintain  an  idle  connection  without  shared 
information  about  timer  values: 

a)  In  accordance  with  ISO  8073/X.224,  Clause  12.2.3.9.a,  all  implementations  must 
respond  to  the  receipt  of  a  duplicate  AK  TPDU  not  containing  FCC  by  transmitting  an 
AK  TPDU  containing  the  'flow  control  confirmation'  parameter; 

b)  Implementations  must  always  transmit  duplicate  AK  TPDUs  without  FCC  on 
expiration  of  the  local  window  timer  (see  ISO  8073/X.224,  Clause  12.2.3.8.1). 
Receipt  of  this  TPDU  by  the  remote  Transport  entity  will  cause  it  to  respond  with  an 
AK  TPDU  containing  the  'flow  control  confirmation'  parameter.  When  this  is  received 
by  the  local  transport  entity,  it  will  reset  its  inactivity  timer.  See  figure  1 ; 

c)  It  is  a  local  matter  for  an  implementation  to  set  the  intervals  of  its  timers  to 
appropriate  relative  values.  Specifically: 

1)  The  window  timer  must  be  greater  than  the  round-trip  delay.  See  5.1.2.3; 

2)  The  inactivity  timer  must  be  greater  than  two  times  the  window  timer;  and 
should  normally  be  an  even  greater  multiple  if  the  Transport  connection  is  to 
be  resilient  to  the  loss  of  an  AK  TPDU. 

A  duplicate  AK  TPDU  (see  figure  1)  is  one  which  contains  the  same  values  for  YR-TU-NR,  credit,  and 
subsequence  number  as  the  previous  AK  TPDU  transmitted.  A  duplicate  AK  TPDU  does  not 
acknowledge  any  new  data,  nor  does  it  change  the  credit  window. 
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Figure  1  -  AK  exchange  on  idle  connection. 


5.1.2.5        Congestion  Avoidance  Policies 

This  clause  defines  both  mandatory  and  optional  requirements  relating  to  avoiding  congestion  in  OSI 
networl<s  and  recovering  from  it  when  it  is  experienced.  The  mandatory  requirements  specify  a 
minimum  approach  to  congestion  avoidance/recovery  which  can  be  tuned  based  upon  the  specific 
requirements  of  the  network.  The  optional  requirements  specify  a  dynamic  window  sizing  scheme 
which,  if  implemented,  will  contribute  further  to  the  avoidance  of  congestion  in  the  network. 

Mandatory  Requirements  are  as  follows: 

a)  A  maxinnum  size  for  the  "receive  credit  window",  the  value  of  which  is  locally 
configurable,  should  be  provided.  A  "receive  credit  window"  reflects  the  number  of 
credits  sent  by  a  Transport  entity  for  a  Transport  connection.  The  maximum  size  of 
the  "receive  credit  window"  shall  be  referred  to  as  WR,; 

b)  A  maximum  size  for  the  "sending  credit  window",  the  value  of  which  is  locally 
configurable,  shall  be  provided.  A  "sending  credit  window"  reflects  the  number  of  data 
TPDUs  that  a  Transport  entity  is  willing  to  send  on  a  Transport  connection.  The 
maximum  size  of  the  "sending  credit  window"  shall  be  referred  to  as  WS,.  As 
specified  in  ISO  8073,  the  "sending  credit  window"  shall  also  be  less  than  or  equal  to 
the  remote  "receive  credit  window"  as  conveyed  in  the  last  CDT  field; 
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c)  It  Is  strongly  recommended  that  an  implementation  use  a  retransmission  timer  per 
Transport  connection.  If,  upon  expiration  of  the  retransmission  timer,  an 
implementation  allows  more  than  "1"  TPDU  to  be  transmitted  a  means  to  locally  adjust 
the  maximum  number  shall  be  provided; 

d)  All  implementations  shall  have  the  capability  of  operating  without  delaying  ACKs  of 
data  TDPUs  received  in-sequence  (i.e.,  Al  essentially  equals  zero).  If  an 
Implementation  optionally  chooses  to  explicitly  delay  ACKs,  a  means  to  locally  adjust 
Al  shall  be  provided. 

Optional  Requirements  are  as  follows: 

For  systems  implementing  the  dynamic  window  sizing  scheme  the  following  rules  apply  as  described 
below: 

1.  RECEIVING  TRANSPORT  ENTITY  (RTE)  RULES: 

a)  Rule  1  -  Initialization  of  Window: 

1)  The  initial  value  of  WR  (known  as  WRq)  shall  have  a  locally  configurable 
upper  bound.  This  window  is  sent  to  the  sending  transport  entity  (STE)  in  the 
next  CDT  field  transmitted; 

a)  Rule  2  -  Required  Sampling  Period: 

1)  All  PTEs  shall  maintain  a  fixed  value  for  WR  until  the  next 
2WR  DT  TPDU  arrive  since  the  last  CDT  field  was  transmitted  by 
the  RTE; 

b)  Rule  3  -  Required  Counting  of  Received  TPDUs  in  a  Sampling 
Period: 

1)  All  RTEs  shall  maintain  a  count,  N,  equal  to  the  total  number 
of  TPDUs  received  and  a  count,  NC,  equal  to  the  total  number 
of  TPDUs  received  which  had  the  CE  Flag  set.  All  types  of 
TPDUs  are  included  in  the  counts  for  N  and  NC,  not  just  DT 
TPDUs; 

c)  Rule  4  -  Required  Action  upon  the  end  of  a  Sampling  Period:  All 
RTEs  shall  take  the  following  actions  at  the  end  of  each  sampling 
period: 

1)  If  the  count  NC  is  less  than  50  percent  of  the  count  N,  the 
RTE  shall  increase  WR  by  adding  1  up  to  a  maximum,  WR,, 
(that  is  based  on  the  local  buffer  management  policy); 
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otherwise,  it  shall  decrease  WR  by  multiplying  by  0.875  (a 
minimum  of  1); 

2)  Reset  N  and  NC  to  zero; 

3)  Transmit  the  new  window  WR  in  the  next  CDT  field  sent  to 
the  sending  transport  entity; 

2)  SENDING  TRANSPORT  ENTITY  (STE)  RULES: 

a)  Rule  1 :      Initialization  of  Window: 

1)  All  STEs  shall  maintain  a  sending  window  size  (WS).  Initially 
and  also  as  long  as  there  is  no  loss,  WS  is  set  equal  to  the 
receiving  window  value  WR  received  from  the  remote  RTE  in  the 
last  CDT  field; 

b)  Rule  2:     Required  Action  on  a  Timeout; 

1)  All  STEs  shall  reset  WS  to  one  when  the  retransmissions 
timer  expires  and  indicates  a  lost  TPDU.  WS  now  limits  the 
number  of  DT  TPDUs  that  may  be  transmitted  or  retransmitted 
without  further  acknowledgments; 

c)  Rule  3:      Required  Counting  of  Acknowledged  TPDU: 

1)  All  STEs  shall  maintain  a  count,  ACKRCVD  of  the  number  of 
DT  TPDUs  acknowledged,  by  the  RTE,  since  WS  was  last 
adjusted.  Therefore  each  time  WS  is  adjusted,  the  count 
ACKRCVD  shall  be  reset  to  zero; 

d)  Rule  4:     Increase  Window  Policy: 

1)  All  STEs  shall  increase  WS  by  one  each  time  ACKRCVD  is 
equal  to  or  greater  than  the  current  value  of  WS,  unless  WS 
exceeds  the  window  permitted  by  the  remote  RTE. 


5.1.2.6        Use  Of  Priority 

(Refer  to  the  Working  Implementation  Agreements). 
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5.2.1       Transport  Class  0  Overview 

Transport  Class  0  over  X.25  is  mandatory  (see  X.400)  for  use  in  communicating  with  public  MHS 
systems  operating  in  accordance  with  the  CCITT  X.400  series  recommendations.  The  purpose  of  the 
agreements  concerning  Transport  Class  0  is  to  allow  connection  to  these  public  services.  Transport 
Class  0  over  X.25  can  also  be  used  in  communicating  between  PRMDs  (this  choice  is  prevalent  outside 
North  America). 


5.2.2       Protocol  Agreements 


5.2.2.1         General  Rules 

Transport  Class  0  agreements  are  as  follows: 

a)  The  Error  (ER)  TPDU  may  be  used  at  any  time  and  upon  receipt  requires  that  the 
recipient  disconnect  the  network  connection,  and  by  extension  the  transport 
connection; 

b)  The  allowed  values  for  the  maximum  TPDU  size  are  128,  256,  512,  1024,  and 
2048; 

c)  The  Class  0  protocol  does  not  support  multiplexing.  At  any  instant,  one  Transport 
corresponds  to  one  Network  connection; 

d)  It  is  recommended  that  the  optional  timers  TS1  and  TS2,  if  implemented,  be 
settable  by  local  system  management.  Values  in  the  order  of  minutes  should  be 
supported; 

e)  An  unlimited  TSDU  length  must  be  supported. 

f)  It  is  recommended  that  implementations  send  both  the  preferred  and  existing 
TPDU  size  parameters  in  the  OR  TPDU. 


5.2.2.2        Transport  Class  0  Service  Access  Points 

For  communicating  with  public  MHS  systems,  section  5  of  X.410  specifies  the  use  and  format  of  TSAP 
identifiers. 
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5.3      Transport  Class  2 


5.3.1       Transport  Class  2  Overview 

Transport  Class  2  is  applicable  in  OSI  end  systems  which  provide  the  Connection-mode  Networl< 
Service. 


5.3.2       Protoco!  Agreements 

Transport  Class  2  agreements  follow: 

a)  The  values  of  the  TS1  and  TS2  timers  shall  be  configurable.  The  recommended 
timer  values  are: 

1)  TS1:  60  seconds; 

2)  TS2:  60  seconds; 

b)  If  present,  the  TSAP-id  field  in  the  CR  and  CC  TPDUs  shall  be  encoded  as  a 
variable  length  field  and  will  be  interpreted  as  an  octet  string.  The  length  of  the  string 
cannot  exceed  32  octets; 

c)  The  rules  for  class  negotiation  shall  be  used; 

d)  QoS  negotiation  is  outside  the  scope  of  these  agreements.  If  QoS  negotiation  is 
not  supported,  receipt  of  the  parameters  "throughput",  "residual  error  rate",  "priority", 
and  "transit  delay"  in  the  CR  and  CC  TPDU  shall  be  ignored. 

NOTE  -  If  Class  0  is  indicated  in  the  Alternative  Protocol  Class  field  and  QoS  parameters  are  conveyed 
and  the  responding  end  system  chooses  Class  0,  then  the  QoS  parameters  have  been  ignored  by  the 
responding  system. 

e)  It  is  recommended  that  implementations  send  both  the  preferred  and  existing  TPDU  size 
parameters  in  the  CR  TPDU. 
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6     Provision  of  Connectionless  Transport  Service 

ISO  8072/Add.  2  is  the  Transport  Service  Definition  covering  Connectionless-mode  Transnnission.  ISO 
8602  is  the  Protocol  for  providing  the  Connectionless-Mode  Transport  Service. 


6.1      Connectionless  Transport  Overview 

When  providing  the  connectionless  Transport  Service,  the  protocol  shall  be  implemented  as  specified  in 
ISO  8602. 


6.2      Protocol  Agreements 


6.2.1       General  Rules 

The  connectionless  Transport  protocol  is  a  relatively  simple  protocol  providing  little  opportunity  for 
conflicting  interpretations.  A  few  relevant  agreements  follow: 

a)  The  optional  elements  of  procedure  for  use  of  CLTS  over  CONS  (i.e.,  clause  6.3  of 
ISO  8602)  will  not  be  supported; 

b)  A  Unitdata  TPDU  that  is  received  that  contains  a  protocol  error  or  an  unknown 
destination  TSAP  ID  shall  be  discarded. 


6.2.2       Connectionless  Transport  Service  Access  Points  or  Selectors 

The  TSAP  selector  field  in  the  UD  TPDU  shall  be  encoded  as  a  variable  length  field  and  will  be 
interpreted  as  an  octet  string.  The  length  of  the  string  cannot  exceed  32  octets. 


7    Transport  Protocol  Identification 

The  absence  of  Call  User  Data  (CUD)  in  an  X.25/ISO  8208  Call  Request/Incoming  Call  packet  indicates 
the  operation  of  ISO  8073/CCITT  X.224. 

Protocol  Identification  TPDU  values  applicable  to  these  agreements  are  given  in  table  1 .  These  TPDUs, 
when  used,  are  conveyed  as  N-connect  user  data. 
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Table  1  -  Protocol  Identification  TPDU  Values 


TPDU  Value 

Protocol 

03    01    01    00  * 
(see  note  1) 
03    01    02    00  ** 
(see  note  2) 

ISO  8073/Add.  1 
ISO  8602 

NOTES 

1  Corresponds  to  an  ISO  8073/Add.  1  UN-TPDU  and  a  X.224  Annex  B  PI-TPDU. 

2  Corresponds  to  an  ISO  8073/Add.  1  UN-TPDU. 
The  following  agreennents  apply: 

a)  Any  additional  TPDU,  which  follows  (by  concatenation)  a  Protocol  Identification  TPDU  shall 
be  ignored  If  ISO  8073/Add.  1  is  not  supported; 

b)  When  using  ISO  8208,  usage  of  a  Protocol  Identification  TPDU  not  corresponding  to  those 
listed  in  table  1  is  outside  the  scope  of  these  agreements. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Upper  Layers  Special  Interest 
Group  (ULSIG)  of  the  National  Institute  of  Standards  and  Technology  (NIST)  Workshop  for  Implementors 
of  Open  Systems  Interconnection  (01 W).  The  charter  for  the  01 W  is  located  in  the  Procedures  Manual. 

The  text  in  this  part  has  been  approved  by  the  Plenary  of  the  OIW.  This  part  replaces  the  previously 
existing  part  on  the  Upper  Layers. 

Annex  A  is  for  information  purposes  only.  Annex  B  forms  an  integral  part  of  these  Implementor 
Agreements. 

Future  changes  and  additions  to  these  Implementor  Agreements  will  be  published  as  change  pages. 
Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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0  Introduction 

Editor's  Note  -  The  word  "NIST"  will  be  removed  from  places  tt  appears  in  tiife  part  as  soon  as  possibfe 

In  this  portion  of  the  Innplementors'  Agreements,  the  MST  Upper  Layers  SIG  is  primarily  concerned  with 
providing  implementation  agreements  for  ACSE,  ROSE,  RISE,  and  the  Presentation  and  Session  layers, 
so  that  systems  Implemented  according  to  these  agreements  can  successfully  interoperate. 


1  Scope 

The  agreements  In  this  part  apply  to  all  ASE  agreements  in  this  document.  Each  ASE  SIG  chooses 
which  protocols,  functional  units,  application  contexts,  and  parameters  it  requires.  These  must  be  listed 
In  the  "Specific  ASE  Requirements"  clause  of  this  part. 


2     Normative  References 


2.1      Session  Layer 

[1]       ISO  8326:  1987  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic 
Connection  Oriented  Session  Service  Definition. 

[2]       ISO  8327:  1987  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic 
Connection  Oriented  Session  Protocol  Specification. 

[3]       ISO/I  EC  JTC1/SC21  N2494,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Basic  Connection  Oriented  Session  Sen/ice  Definition-AD  2  to  ISO  8326  to  Incorporate 
Unlimited  User  Data. 

[4]       ISO/IEC  JTC1  /SC21  N2495,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Basic  Connection  Oriented  Session  Protocol  Specification  -  AD  2  to  ISO  8327  to  Incorporate 
Unlimited  User  Data. 

[5]       IS0/AD3  8326,  Information  Processing  Systems  -  Open  Systems  Interconnection-Session 
Service  Definition:  Addendum  3  Covering  Connectionless-Mode  Session  Service. 

[6]       ISO/IS  9548,  Information  Processing  Systems  -  Open  Systems  Interconnection-Connectionless 
Session  Protocol  to  Provide  the  Connectionless-f^ode  Session  Service. 
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2.2      Presentation  Layer 

[7]       ISO  8822:  1988  (ISO/IEC  JTC1  /SC21  N2335),  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Connection-Oriented  Presentation  Service  Definition. 

[8]       ISO  8823:  1988  (ISO/IEC  JTCI  /SC21  N2336),  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Connection  Oriented  Presentation  Protocol  Specification. 

[9]       ISO  8824:  1990  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Specification  of  Abstract  Syntax  Notation  One  (ASM.  1). 

[10]      ISO  8825:  1990  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.  1). 

[11]     IS0/DAD1  8822:  1989-02-15(e)  (ISO/IEC  JTC1/SC21  N  3171),  Information  Processing  Systems  - 
Open  Systems  Interconnection  -  Presentation  Service  Definition:  Draft  Addendum  1  Covering 
Connectionless-Mode  Presentation  Sen/ice. 

[12]      ISO/IS  9576:  1989-02-25  5(E)  (ISO/IEC  JTC1/SC21  N  3172),  Information  Processing  Systems  - 
Open  Systems  Interconnection  -  Connectionless  Presentation  Protocol  to  Provide  the 
Connectionless-f\/Jode  Presentation  Service. 


2.3      Application  Layer 

[13]     ISO/DP  9545,  ISO/TC97/SC21/N1743,  July  24,  1987,  revised  November  1987,  Information 
Processing  Systems  -  Open  Systems  Interconnection  -  Application  Layer  Structure. 


2.4      Application  Layer  -  ASE/ACSE 

[14]      ISO  8649:  1987  (E)  (ISO/IEC  JTC1/SC21  N2326),  Information  Processing  Systems  -  Open 
Systems  Interconnection  -  Service  Definition  for  the  Association  Control  Sen/ice  Element. 

[15]     ISO  8650:  1987  (E)  (ISO/IEC  JTC1/SC21  N2327),  Information  Processing  Systems  -  Open 

Systems  Interconnection  -  Protocol  Specification  for  the  Association  Control  Service  Element. 

[16]      ISO  8649/DAD2,  Information  Processing  System  -  Open  Systems  Interconnection  -  ACSE 
Sen/ice  Definition:  Draft  Addendum  2  Covering  Connectionless-Mode  ACSE  Service. 

[17]     ISO  8649/DAD1  (ISO/IEC  JTC1/SC21  N3771),  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Service  Definition  for  the  Association  Control  Service  Element  -  Addendum  1 : 
Peer-Entity  Authentication  During  Association  Establishment 

[18]     ISO  8650/DAD1  (ISO/IEC  JTC1/SC21  N3772),  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Protocol  Specification  for  the  Association  Control  Service  Element  - 
Addendum  1 :  Peer-Entity  Authentication  During  Association  Establishment 


2 


Part  5  -  Upper  Layers  June  1991  (Stable) 

i$0  8649/Cor.1 : 1991  (tSO^fiC  aTCl/$C21  N5630^,  intome^fon  Processing  Systems  -  Open 
^^ems  friimiomectton^Tecimicaf  Corngendtm  iioACSE  Service  (ISO  8649;  1988)  Covering 

jaal    iSO  86$a/Cor.1 ;  1981  (E)  (tSO/iEC OTOl/SCai  wnR^i^  mmstfon pfO00s$tfig  SystBms  -  Open 
Sy^ms  fnmooftnectfon  *  Tecfmtcaf  Corrigent  :iSB  Proiooof  (ISO  86S0: 1 986} 

Covwlnfil  Defects  8650/DOI,  864^/904. 

[20]     ISO  IS  10035:  1989-02-25  (ISO/IEC  JTC1/SC21  N  3456),  Information  Processing  Systems  - 

Open  Systems  Interconnection  -  Connectionless  ACSE  Protocol  to  Provide  the  Connectionless- 
Mode  ACSE  Service. 

3  Status 

This  text  is  stable,  as  of  March,  1001. 

NOTE  -  Changes  due  to  errata  are  summarized  in  clause  4 
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4  Errata 

4.1  ISO  Defect  Solutions 

This  clause  lists  the  defect  solutions  from  ISO  which  are  currently  recognized  to  be  valid  for  the 
purposes  of  NIST  conformance. 

ISO  8326  defect  solutions: 

023,  024 
ISO  8327  defect  solutions: 

037,  038 

4.2  Session  Defect  Solutions  Correcting  CCITT  X.215  and  X.225 

The  following  approved  defect  solutions  have  been  integrated  into  the  current  revisions  of  ISO  8326  and 
ISO  8327,  but  are  not  part  of  CCITT  X.215  and  X.225  (1984).  The  defect  solutions  must  be  incorporated 
into  CCITT  Session  to  insure  conformance  with  ISO  Session. 

ISO  8326  defect  solutions: 

004,  006,  007,  009,  Oil,  012,  013,  014,  015,  016,  017,  020. 
ISO  8327  defect  solutions: 

001,  003,  004,  005,  006,  007,  008,  009.  010,  012,  017,  018,  019,  026,  027,  030,  034,  035. 

4.3  Errata  Approved  by  March,  1991  Appro\ 

Errata  to  this  part  are  marked  with  change  bars;  deleted  text  is  left  but  with  strikeouts.  The  following 
table  indicates  the  clause  and  type  for  each  erratum. 

NOTE  -  Shaded  area  indicates  changes  approved  at  the  March  1991  meeting. 
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Clause 

Type 

Comment 

4.3 

editorial 

added  errata  summary  table 

5.2 

editorial 

grammar 

8.3.7 

editorial 

spelling 

0,0,1. 

8.5.1 

editorial 

extraneous  word 

8.7 

editorial 

update  to  document  reference 

Q  A 

tSUX  UVyL  J.  dX 

J.  J 

6a X  uQ/x  X  cix 

JUvJ  VcfU    aWiUC    CIX^o  L  X  Oi\^  C    ajfllCCIA^o     ov./     LlidU    dXX  dX/oUXdv^L 

ojfilUdAvSo     dXC?     XXo  L.  XiSA     UiiU6  X     IT  X  tfo         t.d  C  X  \JIL 

X  6^j[U  X  X  dUcil  If  o  f     UoX                   OVi/IUCr                       X  d  U             I,  X  dils  X  X 

syii^dX  eiiu  X  X  es  so  ^nd^   unex  e  x  s  ozixy  0116 

X  O  X  CX  %3ilwt3     CO    AaoOv^  X  d  t  OU     U  X  diio  X     X     O  J^ii  U  dJw    ^^X     ^  L  \JLl^ 

of  abstract  syntaxes 

/^hsnnp^   4-D  th*>  PHf"o<1ir»fi  r>f   two  KTAM  ah^'hrar't' 

syntaxes:  "NBS  abstract  syntax  ASl"  and  "NBS  file 
directorv  entrv  abstract  svntax" 

\^\JL  XCftX 

B.2 

editorial 

added  explanatory  note  on  nil  application  context 

2.3 

editorial 

delete  references  already  provided  in  MHS 

3. 

editorial 

add  note  that  changes  are  summarized  in  clause  4 

5.5 

editorial 

delete  4  last  line  as  not  applicable 

2.2 

alignment 

delete  references  to  ISO  8825/PDAD  1  and  ISO  8824/ 
PDAD  1  and  change  references  to  1990  version 

9.3.4 

alignment 

session  use  of  transport  expedited  service  is 
optional 

5.3.3 

Working  ->  Stable 

13.7.1 

Working  ->  Stable 

5    Association  Control  Service  Element 


5.1  Introduction 

This  clause  details  the  implementation  requirements  for  the  Association  Control  Service  Element  (ACSE) 
of  the  Application  layer  as  defined  in  ISO  8649  and  ISO  8650. 


5.2  Services 

All  ACSE  services  are  within  the  possible  scope  of  a  NIST-conformant  system. 
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5.3      Protocol  Agreements 


5.3.1  Application  Context 

Values  for  and  uses  of  Application  Context  names  are  determined  by  specific  ASEs.  Values  used  by 
NIST  ASE  SIGS  are  listed  in  the  clause  entitled  "Specific  ASE  Requirements". 

5.3.2  AE  Title 

AE-titles  shall  be  implemented  as  specified  in  Amondmont  1  to  ISO  8660  (ISO  8650/AM4)  Corr.t. 

5.3.3  Peer  Entity  Authentication 

If  supported,  peer-entity  authentication  during  association  establishment  shall  be  implemented  as 
specified  in  Addendum  1  to  ISO  8650  (ISO  8650/DAD1). 

5.4  ASN.1  Encoding  Rules 

When  the  ABRT  APDU  is  used  during  the  connection  establishment  phase,  Presentation  layer  negotiation 
is  considered  to  be  complete,  and  the  "direct-reference"  component  of  EXTERNAL  shall  not  be  present. 

5.5  Connectionless 

The  connectionless  ACSE  protocol  shall  be  implemented  as  specified  in  ISO  DIS  10035. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  part  have  been  made  regarding  this 
standard. 
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ROSE 


ROSE  shall  be  implemented  as  specified  In  ISO  DIS  9072-1.2  and  ISO  DIS  9072-2.2. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  part  have  been  made  regarding  this 
standard. 


RISE  shall  be  implemented  as  specified  in  ISO  9066-1  and  ISO  9066-2. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  part  have  been  made  regarding  this 
standard. 


8  Presentation 


8.1  Introduction 

This  clause  details  the  implementation  requirements  for  the  Presentation  layer  as  defined  in  the 
Presentation  Service  Definition,  ISO  8822,  and  the  Presentation  Protocol  Definition,  ISO  8823. 

The  task  of  the  Presentation  layer  is  to  carry  out  the  negotiation  of  transfer  syntaxes  and  to  provide  for 
the  transformation  to  and  from  transfer  syntaxes.  The  transformation  to  and  from  a  particular  transfer 
syntax  is  a  local  implementation  issue  and  is  not  discussed  within  this  clause.  This  clause  is  concerned 
with  the  protocol  agreements,  and  thus  is  entirely  devoted  to  the  issues  involved  with  the  negotiation  of 
transfer  syntaxes  and  the  responsibilities  of  the  Presentation  protocol. 


8.2  Service 

Only  the  Kernel  functional  unit  need  be  supported.  The  Context  Management  and  Context  Restoration 
functional  units  are  outside  the  scope  of  these  agreements. 

The  requirement  that  the  Presentation  kernel  functional  unit  be  implemented  does  not  imply  that  any  of 
the  Session  functional  units  for  expedited  data,  typed  data,  and  capability  data  and  the  corresponding 
Presentation  service  primitives  are  required  to  be  implemented. 
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8.3      Protocol  Agreements 


8.3.1       Transfer  Syntaxes 

The  following  transfer  syntax  must  be  supported  for  all  mandatory  abstract  syntaxes:  the  basic  encoding 
rules  for  ASN.1.  This  syntax  is  derived  by  applying  the  basic  encoding  rules  for  ASN.1  to  the  abstract 
syntax  (see  the  Basic  Encoding  Rules  for  ASN.1,  ISO  8825). 

The  number  of  transfer  syntaxes  proposed  is  dependent  upon  the  recognized  transfer  syntaxes  which 
are  available  to  support  the  particular  abstract  syntaxes  used  by  an  Application  Entity. 


8.3.2       Presentation  Context  Identifier 

A  conformant  implementation  shall  encode  Presentation  context  identifiers  in  the  range  0  to  32,767. 
Implementations  must  be  able  to  handle  a  minimum  of  two  Presentation  contexts  per  connection. 


8.3.3       Default  Context 

If  the  Presentation  expedited  data  service  is  required,  the  default  context  must  be  explicitly  present  in  the 
P-CONNECT  PPDU  at  Presentation  connect  time. 


8.3.4  P-Selectors 

Local  P-selectors  shall  be  a  maximum  of  four  octets.  This  applies  only  to  P-selectors  in  PPDUs  whose 
receipt  by  an  NIST-conformant  system  normally  results  in  either  a  P-CONNECT  indication  or  a  P- 
CONNECT  confirmation  being  issued. 


8.3.5       Provider  Abort  Parameters 

No  conformance  requirements  are  implied  by  the  use  of  either  the  Abort-reason  or  the  Event-identifier 
component  of  the  ARP-PPDU.  The  decision  to  include  these  parameters  is  left  up  to  the  implementation 
issuing  the  abort. 


8.3.6       Provider  Aborts  and  Session  Version 

The  Presentation  Provider  Abort  PPDU  (ARP-PPDU)  shall  be  present  regardless  of  the  Session  version  in 
effect  for  a  given  association.  This  precludes  the  use  of  indefinite  length  encoding  of  an  ARP-PPDU 
when  Session  Version  1  is  in  effect. 
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8.3.7  CPC-Type 

Implementations  shall  not  use  any  CPC-type  values  in  the  SS-user  data  parameter  of  the  S-CONNECT 
unless  more  than  one  transfer  syntax  is  proposed  for  a  single  Presentation  context  of  the  Presentation 
data  values.  Each  CPC-type  represents  a  unique  transfer  syntax,  so  if  more  than  one  transfer  syntax  is 
proposed,  CPC-type  values  may  appear  in  that  SS-user-data  parameter. 

For  a  Presentation  context  for  which  the  Basic  Encoding  Rules  are  a  proposed  transfer  syntax,  all  PDVs 
in  the  user  data  parameter  of  the  CP  PPDU  must  be  encoded  first  using  the  Basic  Encoding  Rules  and 
must  be  examined  by  the  receiving  Presentation  protocol  machine.  Following  CPC-type  values  may  be 
examined  or  ignored  at  the  receiver's  option  (see  ISO  8823,  clause  6.2.5.3). 


8.3.8  Presentation-context-definition-result-Hst 

No  semantics  are  implied  by  the  absence  of  the  optional  Presentation-context-definition-result-list 
component  of  the  CPR-PPDU.  This  component  is  required  if  the  Provider-reason  is  absent  in  the  CPR- 
PPDU.  If  the  Provider-reason  is  present,  then  the  Presentation-context-definition-result-list  is  optional. 


8.3.9  RS-PPDU 

The  Presentation-context-identifier-list  shall  not  be  present  when  only  the  kernel  functional  unit  is  in 
effect. 


8.4      Presentation  ASN.1  Encoding  Rules 

If  a  received  PPDU  contains  any  improperly  encoded  data  values  (including  data  values  embedded 
within  the  User  Data  field  of  a  PPDU)  and  an  abort  is  issued,  then  either  an  ARU  or  an  ARP  shall  be 
issued. 


8.5  General 

A  Presentation  data  value  (PDV)  is  a  value  of  a  type  in  an  abstract  syntax,  e.g.,  a  value  of  an  ASN.1 
type. 

A  PDV  may  contain  embedded  PDVs  in  different  contexts.  A  change  of  context  within  a  PDV  is  indicated 
by  an  EXTERNAL,  EXTERNAL  implies  an  embedded  PDV. 

A  PDV  cannot  be  split  across  PDV-lists  in  fully-encoded  user  data. 

Fully-encoded-data  that  is  a  series  of  PDVs  in  the  same  Presentation  context  (e.g.,  grouped  FTAM 
PDUs)  shall  be  encoded  either  as  a  single  PDV-list  (using  the  octet-aligned  choice)  or  as  a  series  of 
PDV-lists,  each  encoding  either  a  single  PDV  (using  the  single-ASNI-type  choice)  or  multiple  PDVs 
(using  the  octet-aligned  choice).  Note  that  receivers  must  accept  any  of  the  above  encodings. 
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The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  be  present  In  a  CP  PPDU  If  and  only  if 
more  than  one  transfer  syntax  name  was  proposed  for  the  Presentation  context  of  the  Presentation  data 
values.  The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  always  be  present  in  a  CPC-type. 
If  only  the  Kernel  functional  unit  is  negotiated,  then  the  Transfer-syntax-name  component  of  a  PDV-list 
value  shall  only  appear  in  the  CP  PPDU  and  CPC-type. 


8.7  Connectionless 

The  connectionless  Presentation  protocol  shall  be  implemented  as  specified  in  ISO  9576. 

The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  be  present  in  a  UD  PPDU  if  and  only  if 
more  than  one  transfer  syntax  name  was  proposed  for  the  Presentation  context  of  the  Presentation  data 
values.  The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  always  be  present  in  a  UDC-type. 
The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  only  appear  in  the  UD  PPDU  and 
UDC-type. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  part  have  been  made  regarding  this 
standard. 


9  Session 


9.1  introduction 

This  clause  details  the  implementation  requirements  for  the  Session  layer  as  defined  in  the  Session 
Service  Definition,  ISO  8326  and  the  Session  Protocol  Definition,  ISO  8327. 


9.2  Services 

The  following  functional  units  are  within  the  scope  of  a  NIST  conformant  system: 


a) 

Kernel; 

b) 

Duplex; 

c) 

Expedited  Data; 

d) 

Resynchronize; 

e) 

Exceptions; 

f)  Activity  Management; 
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g)  Half-duplex; 

h)  Minor  Synchronize; 

i)  Major  Synchronize; 
j)  Typed  Data. 

9.3      Protocol  Agreements 

9.3.1  Concatenation 

When  a  category  0  SPDU  is  concatenated  with  a  category  2  SPDU,  the  category  0  SPDU  shall  not 
contain  User  Data. 

Extended  concatenation  is  not  required  and  can  be  refused  using  the  normal  negotiation  mechanisms  of 
the  Session  protocol. 

9.3.2  Segmenting 

Session  segmenting  is  not  required  and  can  be  refused  using  the  normal  negotiation  mechanisms  of  the 
Session  protocol.  All  conformant  implementations  shall  be  able  to  interwork  without  Session  segmenting. 

9.3.3  Reuse  of  Transport  Connection 

Reuse  of  a  Transport  connection  is  not  required  and  can  be  refused. 

9.3.4  Use  of  Transport  Expedited  Data 

The  Session  use  of  Transport  expedited  service  is  optional.  Tho  moaning  of  "supported"  is  spooifiod  in 
clauGO  3.1  of  ISO  DISP  AFTnn  1. 

NOTE  -  A  referencing  ASE  may  require  that  this  feature  shall  be  offered  by  an  initiating  implementation  if 
it  is  available,  and  that  it  shall  be  accepted  by  a  responding  implementation  if  it  is  available  and  was 
offered. 


9.3.5       Use  of  Session  Version  Number 

Session  Versions  1  and  2  are  recognized.  Each  relevant  NIST  SIG  chooses  the  version  or  versions  of 
Session  which  it  requires  for  a  particular  implementation  phase,  and  these  choices  are  documented  in 
clause  12. 
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Session  Version  2  specifies  tlie  use  of  unlimited  user  data  during  connection  establishment  as  dictated 
by  the  AD  2  to  ISO  8327  to  Incorporate  Unlimited  User  Data. 

All  Session  Version  1  implementations  must  be  able  to  negotiate  Version  1  operation  when  responding 
to  a  CONNECT  (CN)  SPDU  proposing  both  Version  1  and  Version  2. 

In  addition,  all  Session  Version  1  implementations,  upon  receipt  of  a  CONNECT  (CN)  SPDU  proposing 
only  Version  2,  should  respond  with  a  REFUSE  (RF)  SPDU  containing  a  Reason  Code  indicating  that  the 
proposed  version  is  not  supported.  Until  pending  defect  reports  are  adopted,  implementations  may 
disconnect. 

If  Session  Versions  1  and  2  are  both  proposed  in  the  CONNECT  (CN)  SPDU,  then  the  maximum  length 
of  the  User  Data  parameter  value  in  the  CONNECT  (CN)  SPDU  shall  be  512  octets  and  a  PGI  field  of 
193  shall  be  associated  with  this  parameter.  This  implies  that  an  implementation  supporting  both  Session 
Versions  1  and  2  can  establish  a  connection  with  an  implementation  supporting  only  Version  1. 

If  only  Session  Version  2  is  proposed  in  the  CONNECT  (CN)  SPDU,  then  the  maximum  length  of  the 
Session  User  Data  parameter  value  of  the  S-CONNECT  service  request  shall  be  10,240  octets.  This 
restriction  implies  that  the  OVERFLOW  ACCEPT  (OA)  SPDU  and  CONNECT  DATA  OVERFLOW  (CDO) 
SPDU  are  not  used.  If  the  length  of  the  User  Data  parameter  value  is  no  greater  than  512  octets,  then  an 
associated  PGI  field  of  193  shall  be  used,  otherwise  a  PGI  field  of  194  shall  be  used. 

When  Session  Version  2  is  negotiated,  then  in  all  SPDUs  the  maximum  length  of  the  User  Data 
parameter  value  with  an  associated  PGI  field  of  193  shall  be  10,240  octets.  NIST-conformant  Session 
Version  2  implementations  need  only  support  the  maximum  data  lengths  specified  in  the  Specific  ASE 
Requirements  section. 


9.3.6       Receipt  of  Invalid  SPDUs 

Upon  receipt  of  an  invalid  SPDU,  the  SPM  shall  take  any  action  in  A.4.3  of  the  Session  Protocol 
Definition  ISO/IS  8327  except  Action  d. 


9.3.7       Invalid  SPM  Intersections 

If  the  conditions  described  in  A.4.1.2  of  the  Session  Protocol  Definition  ISO/IS  8327  are  satisfied,  the 
SPM  shall  always  take  the  actions  described  by  A.4.1.2  a. 

This  implies  that  no  S-P-EXCEPTION-REPORT  indications  will  be  generated  nor  EXCEPTION  REPORT 
SPDUs  sent  due  to  invalid  intersections  of  the  Session  state  table  resulting  from  received  SPDUs. 


9.3.8  S-Selectors 

S-selectors  shall  be  a  maximum  of  1 6  octets. 
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The  connectionless  Session  protocol  shall  be  implemented  as  specified  in  ISO  9548. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  part  have  been  made  regarding  this 
standard. 


10   UNIVERSAL  ASN.1  ENCODING  RULES 


10.1  TAGS 

The  maximum  value  of  an  ASN.1  basic  encoding  tag  that  need  be  handled  by  an  NIST-conformant 
implementation  shall  be  16,383.  This  is  the  maximum  unsigned  number  that  can  be  represented  in  14 
bits,  therefore,  the  maximum  encoding  of  a  tag  occupies  3  octets. 


10.2    Definite  Length 

The  maximum  value  of  an  ASN.1  length  octets  component  that  need  be  handled  by  an  NIST-conformant 
implementation  shall  be  4,294,967,295.  This  is  the  maximum  unsigned  integer  that  can  be  represented  in 
32  bits,  therefore,  the  maximum  encoding  of  a  length  octets  component  will  occupy  5  octets.  Also,  note 
this  restriction  does  not  apply  to  indefinite  length  encoding. 


10.3  External 

It  is  assumed  that  "Presentation  layer  negotiation  of  encoding  rules"  is  always  in  effect,  and  therefore 
clause  32.5  of  the  Specification  of  ASN.1,  ISO  8824  never  applies. 

If  a  data  value  to  be  encapsulated  in  an  EXTERNAL  type  is  an  instance  of  a  single  ASN.1  type  encoded 
according  to  the  Basic  Encoding  Rules  for  ASN.1,  then  the  option  "single-ASN.I-type"  shall  be  chosen  as 
its  encoding. 

If  a  data  value  to  be  encapsulated  in  an  EXTERNAL  type  is  encoded  as  an  integral  number  of  octets, 
and  the  above  does  not  apply,  then  the  option  "octet-aligned"  shall  be  chosen  as  its  encoding. 


10.4  Integer 

Any  incidence  of  an  ASN.1  INTEGER  type  defined  in  an  abstract  syntax  describing  protocol  control 
information  must  be  encoded  so  that  the  length  of  its  contents  octets  is  no  more  than  four  octets,  unless 
an  explicit  NIST  agreement  to  the  contrary  is  made  for  a  specific  INTEGER  type. 
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10.5  String  Types 

The  contents  octets  for  a  constructed  encoding  of  a  BIT  STRING.  OCTET  STRING,  or  character  string 
value  consists  of  the  complete  encoding  of  zero,  one,  or  more  data  values,  and  the  encoding  of  these 
data  values  must  be  primitive. 

10.6  Bit  String 

Unless  othenA/ise  specified  in  the  abstract  syntax  definition,  each  bit  named  in  a  BIT  STRING  type  used 
in  that  abstract  syntax  definition  shall  be  explicitly  encoded  in  the  associated  BIT  STRING  value,  even  if  it 
Is  part  of  a  string  of  trailing  zero  bits. 

Extra  trailing  bits  beyond  the  exact  number  of  bits  which  correspond  to  the  complete  list  of  the  named 
bits  specified  shall  never  be  encoded.  This  rule  applies  to  all  BIT  STRING  types  unless  stated  othenA^ise 
in  the  standards. 


1 1   Character  Sets 

See  Part  21  of  Working  Implementation  Agreements. 


12  Conformance 

In  order  for  an  implementation  to  be  in  conformance  with  the  NIST  implementors'  agreements,  the  rules 
below  shall  be  followed: 

a)  A  conformant  implementation  must  meet  all  of  the  requirements  of  this  specification.  All 
documents  referenced  in  the  Upper  Layers  part  shall  be  used  as  the  supporting  documents  for 
all  implementations  of  ACSE,  ROSE,  RTSE,  Presentation,  or  Session.  The  full  references  for 
these  documents  are  in  clause  2. 

b)  NIST-conformant  implementations  shall  be  ISO  conformant.  PICS  may  contain  limitations  on 
length  or  value  aspects  of  a  protocol.  PICS  of  NIST-conformant  systems  shall  not  contain 
restrictions  more  severe  than  those  in  these  implementation  agreements. 

NOTE  -  An  implementation  may  abort  a  connection  if  the  constraints  specified  in  these  agreements  are 
violated. 
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13  Specific  ASE  Requirements 

The  following  list  for  each  ASE  the  corresponding  NIST  SIG's  requirements  of  and  restrictions  on  ACSE, 
ROSE,  RISE,  Presentation,  and  Session. 

All  listed  requirements  and  restrictions  shall  be  included  in  an  NIST-conformant  system  and  shall  be 
implemented  in  accordance  with  these  NIST  Implementor's  agreements. 

13.1  FTAMPhase2 

13.1.1  ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

Application  Contexts:  "ISO  FTAM"  {  iso(1)  standard (0)  8571  application-context  iso-ftam(1)  }  -  implies 
the  use  of  the  ACSE  and  the  FTAM  ASE. 

A  value  is  defined  for  the  AE  Title  only  to  satisfy  the  FTAM  requirement  for  exchanging  fields  of  this 
type.  This  value  does  not  identify  an  Application  Entity  and  carries  no  semantics. 

If  the  AE  title  is  used,  AE-title-form2  shall  be  supported.  Support  of  AE-title-form2  includes  support  of  AP- 
title-form2  and  AE-qualifier-form2. 

The  value  for  the  AP  title  is  {  1  3  9999  1  ftam-nil-ap-title  (7)  }  at  this  time.  Values  for  the  AE  qualifier  are 
outside  the  scope  of  these  agreements. 

The  use  of  AP  invocation  identifiers  and  AE  invocation  identifiers  by  FTAM  is  outside  the  scope  of  these 
agreements. 

13.1.2  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  At  least  3  Presentation  Contexts  must  be  supported. 
Abstract  Syntaxes: 

a)  Abstract  Syntaxes  for  conformant  Implementations 

1)  "ISO  8650-ACSE1"  {joint-iso-ccitt(2)  association-control (2)  abstract-syntax(1 ) 
apdus(O)  version1(1)  } 

2)  "FTAM-PCI"  {  iso(1)  standard (0)  8571  abstract-syntax(2)  ftam-pci(l)  } 

3)  "FTAM  unstructured  binary  abstract  syntax"  {  iso(1)  standard(O)  8571 
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abstract-syntax(2)  unstructured-binary(4)  } 
Editor's  Note  -  In  Definitions  below,  "NBS"  designation  will  be  preserved. 

b)  Abstract  Syntaxes  Depending  on  implementation  Profile 

1)  "FTAM-FADU"  {  iso(1)  standard(O)  abstract-syntax(2)  ftam-fadu(2)  } 

2)  "FTAM  unstructured  text  abstract  syntax"  {  iso(1)  standard(O)  8571  abstract-syntax(2) 
unstructured-text(3)  } 

3)  "NBS  abstract  syntax  AS1"  {  iso  identified-organization  oiw(1 4)  ftamsig(5) 
abstract-syntax(2)  nbs-asl(l)  } 

4)  "NBS  file  directory  entry  abstract  syntax"  {  iso  identified-organization  oiw(14) 
ftamsig(5)  abstract-syntax(2)  nbs-as2(2)  } 

c)  Associated  Transfer  Syntax: 

1)  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)} 

Editor's  Note  -  The  changes  above  involving  "0IW(14)"  were  not  explicitly  mentioned  at  the  March  1990 
Plenary,  but  were  implied  from  a  correspondingly  approved  FTAM  motion. 

13.1.3  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 

13.1.4  Session  Options 

Session  Functional  Units: 

a)  resynchronize  -  only  a  Resynchronize  Type  value  of  "abandon" 

b)  minor  synchronize 
NOTES 
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1  The  minor  synchronize  functional  unit  is  required  whenever  the  resynchronize  functional  unit  is  available. 

2  The  default  value  for  Minor  Sync  Point  Sync  type  item  shall  always  be  used,  i.e.,  explicit  confirmation  is 
required. 

13.1.5      ASN.1  Encoding  Requirements 

Some  INTEGER  types  of  the  FTAM  PCI  may  exceed  the  maximum  size  specified  in  the  UNIVERSAL 
ASN.1  ENCODING  Rules.  See  the  Range  of  values  for  INTEGER  type  Parameters  of  the  FTAM  part. 

13.2  MHS 

13.2.1  Phase  1  (1984  X.400)  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  half-duplex 

c)  exceptions 

d)  activity  management 

e)  minor  synchronize 
Version  Number:  1 

Maximum  size  of  User  Data  parameter  field:  512 
NOTES 

1  Restricted  use  is  made  by  the  RTS  of  the  Session  services  implied  by  the  functional  units  selected. 
Specifically,  1)  No  use  is  made  of  S-TOKEN-GIVE,  and  2)  S-PLEASE-TOKENS  only  asks  for  the  data  token. 

2  In  the  S-CONNECT  SPDU,  the  Initial  Serial  Number  should  not  be  present. 

3  The  format  of  the  Connection  Identifier  in  the  S-CONNECT  SPDU  is  described  in  Version  5  of  the  X.400- 
Series  Implementors'  Guide. 

13.2.2  Phase  2,  Protocol  PI  (1988  X.400) 
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13.2.2.2  RTSE  Requirements 

The  RTSE  requirements  are: 

a)  Monologue 

b)  TWA  -  optional     \    .■:  . 

c)  checkpointing: 

1)  minimum  checkpointsize  =  1 

2)  minimum  windowsize  =  1 

d)  no  checkpointing 
For  the  Monologue  Association: 

a)  initiator  keeps  initial  turn 

b)  APDUs  are  transferred  from  initiator  to  responder  only 

c)  no  turn  passing 

d)  only  the  initiator  effects  the  orderly  release  of  an  association 
For  the  two  way  alternate  Association 

a)  the  initiator  may  keep  or  pass  the  initial  turn,  at  binding 

b)  APDUs  are  transferred  by  the  holder  of  the  turn 

c)  only  the  initiator  effects  the  orderly  release  of  an  association,  when  it  possesses  the  turn 

13.2.2.3  ACSE  Requirements 

As  per  Phase  2,  Protocol  P7. 
Application  Contexts: 

a)  "MTS-transfer-protocol-1 984"  -  mandatory 

b)  "MTS-transfer-protocol"  -  mandatory 
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13.2.2.4  Presentation  Requirements 

Presentation  Functional  Units:  l<ernel 

Presentation  Contexts:  at  least  3  must  be  supported 

Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {joint-iso-ccitt(2)  association-control (2)  abstract-syntax(l )  apdus(O) 
version1(1)  } 

b)  "MTS-RTSE" 

c)  "MTSE" 

d)  Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2) 
asn1(1)  basic-encoding(l)  } 

13.2.2.5  Session  Requirements 

As  per  Phase  2,  Protocol  P7. 

13.2.3      Phase  2,  Protocol  P7  (1988  X.400) 

13.2.3.1  ROSE  Requirements 

Operation  and  association  classes  are  used  as  per  the  standard. 

13.2.3.2  RISE  Requirements 

The  RTSE  requirements  are: 

a)  TWA 

b)  normal-mode 

c)  checkpointing 

d)  minimum  checkpointsize  =  1 

e)  minimum  windowsize  =  1 
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f)  no  checkpointing 
For  the  Monologue  Association: 

a)  initiator  keeps  initial  turn 

b)  APDUs  are  transferred  from  initiator  to  responder  only 

c)  no  turn  passing 

d)  only  the  initiator  effects  the  orderly  release  of  an  association 
For  two  way  alternate  Association: 

a)  the  initiator  may  keep  or  pass  the  initial  turn,  at  binding 

b)  APDUs  are  transferred  by  the  holder  of  the  turn 

c)  only  the  initiator  effects  the  orderly  release  of  an  association,  when  it  possesses  the  turn 

13.2.3.3  ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

The  use  of  AP-TITLE.  AE-QUALIFIER.  AP-INVOCATION-ID,  and  AE-INVOCATION-ID  is  not 
recommended;  however,  a  receiving  entity  must  be  capable  of  ignoring  them  (if  present)  without  refusing 
the  connection. 

Application  Contexts: 

a)  "MS-access"  -  mandatory;  normal  mode 

b)  "MS-reliable-access"  -  optional;  normal  mode 

13.2.3.4  Presentation  Requirements 

Presentation  Functional  Units:  kernel 
Presentation  Contexts:  at  least  5 
Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {  joint-iso-ccitt(2)  association-control (2)  abstract-syntax(l)  apdus(0) 
version!  (1)  } 

b)  MSBind/MSUnbind  (with  or  without  RISE) 
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c)  MSSE  (Message  Submission) 

d)  MASE  (Message  Administration) 

e)  MRSE  (Message  Retrieval) 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 

13.2.3.5       Session  Requirements 

Session  Functional  Units: 
a)  kernel 

1  b)  half-duplex  (tf  RTSE  is  supportdci) 

I  c)  exceptions  f ult-dupt&x  (If  RT$£  1$  not  supported) 

d)  activity  managomont  6x<:6ptlonE$ 
1  e)  minor  oynchronizo  activity  maitageffl^nt 

Q  minor  synchronize 
Version  Number:  2 

i 

i     Maximum  size  of  User  Data  parameter  field:  10,240 


1  MHS  proposes  both  versions  1  and  2  for  pass  through  mode  (X.410  mode),  but  only  version  2  for 
normal  mode. 

2  Restricted  use  is  made  by  the  RTS  of  the  Session  services  implied  by  the  functional  units  selected. 
Specifically,  no  use  is  made  of  S-TOKEN-GIVE,  and  S-PLEASE-TOKENS  only  asks  for  the  data  token. 

3  In  the  S-CONNECT  SPDU,  the  Initial  Serial  Number  should  not  be  present. 

4  The  format  of  the  Connection  Identifier  in  the  S-CONNECT  SPDU  is  described  in  Version  5  of  the  X.400- 
Series  Implementors'  Guide. 


NOTES 


13.2.4 


Phase  2,  Protocol  P3  (1988  X.400) 
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13.2.4.1  ROSE  Requirements 

As  per  Phase  2,  P7. 

13.2.4.2  RTSE  Requirements 

As  per  Phase  2,  P7. 

13.2.4.3  ACSE  Requirements 

As  per  Phase  2,  P7. 
Application  Contexts: 

a)  "MTS-access"  -  mandatory 

b)  "MTS-reliable-access"  -  optional 

c)  "MTS-forced -access"  -  mandatory 

d)  "MTS-forced-reliable-access"  -  optional 

13.2.4.4  Presentation  Requirements 

As  per  Phase  2,  P7. 

13.2.4.5  Session  Requirements 

As  per  Phase  2,  P7. 

13.3     DS  Phase  1 

13.3.1      ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 
Application  Contexts: 

a)  "id-ac-directoryAccessAC"  {  joint-iso-ccitt(2)  ds(5)  3  1  } 

b)  "id-ac-directorySystemAC"  {  joint-iso-ccitt(2)  ds(5)  3  2} 
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13.3.2  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  At  least  2  Presentation  Contexts  must  be  supported. 
Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {  joint-iso-ccitt(2)  association-control (2)  abstract-syntax(1 )  apdus(O) 
version1(1)  } 

b)  "id-as-directoryAccessAS"  joint-iso-ccitt(2)  ds(5)  9  1  } 

c)  "id-as-directorySystemAS"  {  joint-iso-ccitt(2)  ds(5)  9  2} 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 

13.3.3  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 

13.4    Virtual  Terminal 
13.4.1      Phase  la 

13.4.1.1       ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

Application  Contexts:  "ISO  VT"  {  iso(1)  standard(O)  9041  application-context(l)  }-  implies  the  use  of  the 
ACSE  and  the  VT  ASE 
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13.4.1.2  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  at  least  2  must  be  supported 

Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {  joint-iso-ccitt(2)  association-control (2)  abstract-syntax(1 )  apclus(O) 
version1(1)  } 

b)  "VT  Basic"  {  !So(1)  standard(O)  9041  abstract-syntax(2)  } 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 

13.4.1.3  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 

c)  expedited  data 

d)  major  synchronize 

e)  resynchronize  -  only  a  Resynchronize  Type  value  of  "restart" 

f)  typed  data 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 
Session  Options:  expedited  data 

13.4.2      Phase  1b 

13.4.2.1       ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

Application  Contexts:  "ISO  VT"  {  iso(1)  standard(O)  9041  application-context(l)  }  -  implies  the  use  of  the 
ACSE  and  the  VT  ASE 
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13.4.2.2  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  at  least  2  must  be  supported 

Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {  joint-iso-ccitt(2)  association-control (2)  abstract-syntax(l)  apdus(O) 
version1(1)  } 

b)  "VT  Basic"  {  iso(1)  standard(O)  9041  abstract-syntax(2)  } 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 

13.4.2.3  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 

c)  half-duplex 

d)  expedited  data 

e)  major  synchronize 

f)  resynchronize  -  only  a  Resynchronize  Type  value  of  "restart" 

g)  typed  data 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 
Session  Options:  expedited  data 
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13.5»1     ACSH  Requirements 

ACSE  Ftinc^nal  Units:  Kernel 

Appfication  Context:  ISO  MMS"  {  iso(l)  standard(O)  9506  part(2)  mms-application-context-versiOQt(3)>  - 
Implies  us$  of  ACSE  and  MMS  ASE 

13.5.2     Presentation  Requirements 

Presentation  Functional  Units:  Kernel 

At  lea^  2  Presentation  Contexts  must  be  supported 

Abstract  Syntaxes; 

a)  "mms-abstract-syntax-major-verstonl"  {  1so(l)  standard(0)  9506  partC2}  mms-abstradt^symtaix* 
major-version  1  {1)> 

b)  "ISO  8650-AC$E1"  {joint-iso-ccitt(2)  association-control (2)  abstract-syntax(l)  apdu8(0) 
versiont{t)> 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {joint-isO"CCitt(2)  asnl(1)  basic- 
encoding(i )) 

13*5,3     Session  Requirements 

Session  Functional  Units! 

a)  Kernd 

b}  Duplex 
Version  Number'  2 

Maximum  size  of  User  DaTa  parameter  field:  10.240 
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13.6    Transaction  Processing 

See  Working  Implementation  Agreements  Document. 


September  1991  (Stable) 


13.7    Network  Management 

13.7.1  ROSE  Requirements 

The  Rose  requirements  are  as  specified  in  ISO  9596  section  5.2:  Underlying  Services,  and  section  6.2 
Remote  Operations. 

Operations  Classes:  1 ,  2,  and  5 

Association  Classes:  3 

13.7.2  ACSE  Requirements 

ACSE  Functional  Units:  kernel 
Application  Contexts:  as  defined  by  [SMO] 

AE-Title:  The  association  responder  shall  support  both  forms  of  the  AE-Title.  The  association  requestor 
may  use  either  form  of  the  AE-Title. 

13.7.3  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  At  least  2  must  be  supported. 

Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {  joint-iso-ccitt(2)  association-control (2)  abstract-syntax(l)  apdus(O) 
version1(1)  } 

b)  "CMIP-PCI"  {joint-iso-ccitt(2)  ms(9)  cmip(1)  cmip-pci(1)  abstractSyntax(4)} 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 
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13.7.4      Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240. 


September  1991  (Stable) 
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Annex  A  (informative) 
Recommended  Practices 

The  optional  "Reflect  Parameter  Values"  parameter  in  the  Provider  ABORT  SPDU  shall  be  encoded  so  as 
to  represent  the  Session  connection  state,  the  incoming  event  and  the  first  invalid  SPDU  field  exactly  at 
the  moment  a  protocol  error  was  detected. 

The  first  octet  encodes  the  Session  state  as  a  number  relative  to  0  as  detailed  in  table  1 . 
The  second  octet  encodes  the  incoming  event  as  a  number  relative  to  0  as  detailed  in  table  2. 
The  third  octet  contains  the  SI,  PGI,  or  PI  Code  of  any  SI  field,  PGI  unit  or  PI  unit  in  error. 
NOTE  -  The  remaining  6  octets  are  undefined  herein. 
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Table  1  -  Session  States 


State 

Rel 

Description 

1 

0 

no 

transport  connection 

IB 

1 

VVCl  X  u 

for 

T-connect  confirm 

IC 

2 

Tfll  t> 

XUXt?  f 

transport  connected 

2A 

3 

WCl  X  u 

for 

the  ACCEPT  SPDU 

3 

4 

n  ci  X  u 

for 

the  DISCONNECT  SPDU 

8 

5 

Wait 

for 

the  S-CONNECT  response 

9 

6 

Wait 

for 

the  S-RELEASE  response 

16 

7 

Wait 

for 

the  T-DISCONNECT  indication 

713 

8 

Data 

Transfer  state 

lA 

9 

Wait 

for 

the  ABORT  ACCEPT  SPDU 

4A 

10 

Wai  t 

for 

the  MAJOR  SYNC  ACK  SPDU  or  PREPARE  SPDU 

4B 

11 

Wait 

for 

the  ACTIVITY  END  ACK  SPDU  or  PREPARE  SPDU 

5A 

12 

Wait 

for 

the  RESYNCHRONIZE  ACK  SPDU  or  PREPARE  SPDU 

5B 

13 

Wait 

for 

the  ACTIVITY  INTERRUPT  SPDU  or  PREPARE  SPDU 

5C 

14 

Wait 

for 

the  ACTIVITY  DISCARD  ACK  SPDU  or  PREPARE  SPDU 

6 

15 

Wait 

for 

the  RESYNCHRONIZE  SPDU  or  PREPARE  SPDU 

lOA 

16 

Wai  t 

for 

the  S-SYNC -MAJOR  response 

lOB 

17 

Wait 

for 

the  S-ACTIVITY-END  response 

llA 

18 

Wait 

for 

the  S-RESYNCHRONIZE  response 

IIB 

19 

Wait 

for 

the  S-ACTIVITY-INTERRUPT  response 

lie 

20 

Wait 

for 

the  S-ACTIVITY-DISCARD  response 

15A 

21 

After 

PREPARE,  wait  for  the  MAJOR  SYNC  ACK  SPDU 

or  the  ACTIVITY  END  ACK 

15B 

22 

After 

PREPARE,  wait  for  the  RESYNCHRONIZE  SPDU 

or  the  ACTIVITY  DISCARD  SPDU 

15C 

23 

After 

PREPARE,  wait  for  the  RESYNCHRONIZE  ACK  SPDU, 

or  the  ACTIVITY  INTERRUPT  ACK  SPDU 

or  the  ACTIVITY  DISCARD  ACK  SPDU 

18 

24 

Wait 

for 

GIVE  TOKENS  ACK  SPDU 

19 

25 

Wait 

for 

a  recovery  request  or  SPDU 

20 

26 

Wait 

for 

a  recovery  SPDU  or  request 

21 

27 

Wait 

for 

the  CAPABILITY  DATA  ACK  SPDU 

22 

28 

Wait 

for 

the  S-CAPABILITY-DATA  response 

ID 

29 

Wait 

for 

the  CONNECT  DATA  OVERFLOW  SPDU 

2B 

30 

Wait 

for 

the  OVERFLOW  ACCEPT  SPDU 

15D 

31 

After 

PREPARE,  wait  for  the  ABORT  SPDU 
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Table  2  -  Incoming  Events 


Event 

Rel 

Description 

SCONreq 

0 

S-CONNECT  request 

SCONrsp 

1 

S-CONNECT  accept  response 

SCONrsp 

2 

S-CONNECT  reject  response 

SDTreq 

3 

S-DATA  request 

SRELreq 

4 

S-RELEASE  request 

SRELrsp 

5 

S-RELEASE  accept  response 

SUABreq 

6 

S-U-ABORT  request 

TCONcnf 

7 

T-CONNECT  confirmation 

TCONind 

8 

T-CONNECT  indication 

TDISind 

9 

T-DISCONNECT  indication 

TIM 

10 

Time  out 

AA 

11 

ABORT  ACCEPT 

AB-nr 

12 

ABORT  -  no  reuse 

AC 

13 

ACCEPT 

CN 

14 

CONNECT 

DN 

15 

DISCONNECT 

DT 

16 

DATA  TRANSFER 

FN-nr 

17 

FINISH  -  no  reuse 

RF-nr 

18 

REFUSE  -  no  reuse 

SACTDreq 

19 

S-ACTIVITY-DISCARD  request 

SACTDrsp 

20 

S-ACTIVITY-DISCARD  response 

SACTEreq 

21 

S-ACTIVITY-END  request 

SACTErsp 

22 

S-ACTIVITY-END  response 

SACTIreq 

23 

S-ACTIVITY-INTERRUPT  request 

SACTIrsp 

24 

S -ACTIVITY- INTERRUPT  response 

SACTRreq 

25 

S-ACTIVITY-RESUME  request 

SACTSreq 

26 

S-ACTIVITY-START  request 

SCDreq 

27 

S-CAPABILITY-DATA  request 

SCDrsp 

28 

S-CAPABILITY-DATA  response 

SCGreq 

29 

S -CONTROL-GIVE  request 

SEXreq 

30 

S-EXPED I TED-DATA  request 

SGTreq 

31 

S-TOKEN-GIVE  request 

SPTreq 

32 

S-TOKEN-PLEASE  request 

SRELrsp 

33 

S-RELEASE  response  reject 

SRSYNreq(a) 

34 

S-RESYNCHRONIZE  request  abandon 

SR<?YNrpa  <  r  \ 

15 

SRSYNreq(s) 

36 

S-RESYNCHRONIZE  request  set 

SRSYNrsp 

37 

S-RESYNCHRONIZE  response 

SSYNMreq 

38 

S-SYNC-MAJOR  request 

SSYNMrsp 

39 

S-SYNC-MAJOR  response 

SSYNmreq 

40 

S-SYNC -MINOR  request 

SSYNmrsp 

41 

S-SYNC -MINOR  response 

STDreq 

42 

S-TYPED-DATA  request 

SUERreq 

43 

S-U-EXCEPTION-REPORT  request 
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Table  2  -  Incoming  Events  (continued) 


Event 

Rel 

Description 

AB-r 

44 

ABORT  -  reuse  SPDU 

AD 

45 

ACTIVITY  DISCARD  SPDU 

ADA 

46 

ACTIVITY  DISCARD  ACK  SPDU 

AE 

47 

ACTIVITY  END  SPDU 

AEA 

48 

ACTIVITY  END  ACK  SPDU 

AI 

49 

ACTIVITY  INTERRUPT  SPDU 

AIA 

50 

ACTIVITY  INTERRUPT  ACK  SPDU 

AR 

51 

ACTIVITY  RESUME  SPDU 

AS 

52 

ACTIVITY  START  SPDU 

CD 

53 

CAPABILITY  DATA  SPDU 

CDA 

54 

CAPABILITY  DATA  ACK  SPDU 

ED 

55 

EXCEPTION  DATA  SPDU 

ER 

56 

EXCEPTION  REPORT  SPDU 

EX 

57 

EXPEDITED  DATA  SPDU 

FN-r 

58 

FINISH  -  reuse  SPDU 

GT 

59 

GIVE  TOKENS  SPDU 

GTA 

60 

GIVE  TOKENS  ACK  SPDU 

GTC 

61 

GIVE  TOKENS  CONFIRM  SPDU 

MAA 

62 

MAJOR  SYNC  ACK  SPDU 

MAP 

63 

MAJOR  SYNC  POINT  SPDU 

MIA 

64 

MAJOR  SYNC  ACK  SPDU 

MIP 

65 

MINOR  SYNC  POINT  SPDU 

NF 

66 

NOT  FINISHED  SPDU 

PR-MAA 

67 

PREPARE   (MAJOR  SYNC  ACK)  SPDU 

PR-RA 

68 

PREPARE   (RESYNCHRONIZE  ACK)  SPDU 

PR-RS 

69 

PREPARE   (RESYNCHRONIZE)  SPDU 

PT 

70 

PLEASE  TOKENS  SPDU  with  Token  Item  Paramet  r 

RA 

71 

RESYNCHRONIZE  ACK  SPDU 

RF-r 

72 

REFUSE  -  reuse  SPDU 

RS-a 

73 

RESYNCHRONIZE  -  abandon  SPDU 

RS-r 

74 

RESYNCHRONIZE  -  restart  SPDU 

RS-S 

75 

RESYNCHRONIZE  -  set  SPDU 

TD 

76 

TYPED  DATA  SPDU 

CDO 

77 

CONNECT  DATA  OVERFLOW  SPDU 

0A7 

80 

VERFLOW  ACCEPT  SPDU 

PR-AB 

79 

PREPARE   (ABORT)  SPDU 
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Annex  B  (normative) 
Object  Identifier  Register 


B.1      Register  Index 

Each  entry  in  the  index  contains  an  object  identifier  value  and  a  reference  to  the  clause  describing  the 
object  identifier's  use: 

a)  {  iso(l)  identified-organization(3)  oiw(14)  ulsig(8)  application-context(l)  nil(1)  }  is  defined  in 
14.2; 

b)  {  iso(1)  identified-organi2ation(3)  oiw(14)  ulsig(8)  abstract-syntax(2)  octet-string(l)  }  is 
defined  in  14.2. 


B.2     Object  Identifier  Descriptions 

{  iso(1)  identified-organization(3)  oiw(14)  ulsig(8)  application-context(l)  nil(1)  } 

This  application  context  may  be  used  by  applications  having  a  prior  agreement  regarding  the  application 
context. 

NOTE  -  This  value  is  intended  to  be  used  by  private  applications  that  have  an  a  priori  agreement 
concerning  the  set  of  ASEs,  related  options,  and  any  other  information  necessary  for  the  interworking  of 
AEs  on  an  application  association.  This  value  does  not  identify  any  specific  application  context  and  cannot 
be  used  to  identify  the  intended  communications  environment  for  the  application  association.  Therefore,  it 
is  strongly  recommended  that  private  applications  define  and  register  an  object  identifier  for  their 
application  context. 

{  iso(1)  identified-organization(3)  oiw(14)  ulsig(8)  abstract-syntax(2)  octet-string(l)  } 


NIST-OIW-ULSIG-AS-octet 

-string 

DEFINITIONS 

::=  BEGIN 

Single-octet-string 

: : =    OCTET  STRING 

END 

This  abstract  syntax  may  be  used  by  applications  having  a  prior  agreement  regarding  the  content  of  the 
octet  string. 
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PART  6  -  REGISTRATION  AUTHORITY  PROCEDURES  FOR  THE  OSI  IMPLEMENTORS 
WORKSHOP  (OIW)  December  1990  (Stable) 


Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Registration  Special  Interest  Group 
(RSIG)  of  the  National  Institute  of  Standards  and  Technology  (NIST)  Workshop  for  Implementors  of  Open 
Systems  Interconnection  (OSI). 

This  part  replaces  the  previously  existing  chapter  on  this  subject.  There  is  no  significant 
technical  change  from  this  text  as  previously  given. 
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Part  6  -  Registration  Authority  Procedures  for  the  OSI  Implementors 
Workshop  (OIW) 

NOTE  -  Previous  material  in  this  section  has  been  deleted  and  is  no  longer  applicable. 

This  chapter  establishes  the  policies  and  procedures  for  the  registration  of  technical  objects  defined  by  the 
OSI  Implementors  Worl<shop.  Procedures  for  registering  operational  and  administrative  objects,  such  as  the 
MHS  ADMD  and  PRMD  names  and  addresses,  are  outside  the  scope  of  this  chapter. 


0  Introduction 

In  order  to  communicate,  it  is  necessary  to  identify  the  objects  involved  in  communication.  These  objects 
have  names  and  addresses.  A  name  identifies  an  object  within  the  domain  of  a  registration  authority.  An 
address  is  a  name  that  is  used  to  specify  the  physical  or  logical  location  of  an  object. 

OSI  names  and  addresses  consist  of  attributes  which  are  hierarchical  in  nature  and  which  combine  to 
identify  or  locate  an  OSI  object  unambiguously.  Since  the  relationship  between  the  components  of  a  name 
or  address  is  hierarchical,  it  follows  that  the  registration  authority  for  names  and  addresses  should  also  be 
hierarchical.  A  governing  organization  does  not  always  have  sufficient  knowledge  of  organizations  lower 
in  the  hierarchy  to  assign  values  within  those  organizations.  Thus,  an  approach  frequently  taken  is  to 
delegate  registration  authority  to  the  lower  organizations. 

Hierarchy  implies  an  inverted  tree-like  structure  where  the  number  of  objects  increases  from  the  root  of  the 
tree  to  the  leaves  of  the  tree.  At  the  root  of  the  tree,  there  is  one  designator  that  has  the  greatest  scope 
of  authority  (largest  domain).  This  designator  assigns  identifier  values  to  objects  under  its  authority.  Each 
of  these  objects  has  a  smaller  scope  of  authority  than  the  objects  immediately  above  and  may  create  zero, 
one,  or  many  subauthorities  at  the  next-lower  level.  The  number  of  levels  in  such  a  tree-like  structure  is 
arbitrary. 


1  Scope 

This  part  defines  registration  procedures  for  OSI  Implementors  Workshop  (OIW)  information  objects  and 
identifies  additional  registration  requirements.  These  procedures  shall  be  used  by  the  Special  Interest 
Groups  (SIGs)  of  the  Workshop  to  register  information  objects  used  in  OSI  communications  according  to 
the  OIW  Agreements  Document. 

In  this  part,  the  OIW  and  the  SIGs  themselves  are  assigned  arcs  in  the  object  identifier  tree.  These  arcs  are 
for  OlW-specified  objects.  The  SIGs  should  note  that,  as  national  and  international  registration  authorities 
are  established,  objects  of  interest  beyond  the  Workshop  are  more  appropriately  registered  by  a  higher  level 
in  the  hierarchy.  This  will  allow  more  widespread  acceptance  of  the  registered  objects. 

This  part  is  structured  as  follows:  6.2  describes  the  information  objects  that  need  to  be  registered,  and  6.3 
describes  a  registration  procedures  for  OIW  object  identifiers.  Annex  A  lists  the  object  identifier  component 
values  assigned  to  the  OIW  and  the  SIGs.  Annex  B  discusses  object  identifiers  used  in  the  1987  and  1988 
Stable  Implementation  Agreements.  The  appendices  are  integral  parts  of  this  specification. 
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2     Normative  References 


3     Registered  Information  Objects 

If  networks  are  to  interoperate  as  envisioned  in  the  OSI  model,  there  must  be  a  universal  open  and  agreed 
upon  naming  schema.  There  are  many  information  objects  that  fall  under  this  requirement. 

Some  of  the  foliov\/ing  objects  are  registered  in  the  standards,  some  are  registered  by  OIW  and  others  by 
other  registration  authorities.  An  example  list  of  objects  to  be  registered  is: 

a)  Application-process-titles; 

b)  Application-entity-titles; 

c)  Abstract  syntaxes; 

d)  Transfer  syntaxes; 

e)  Application-contexts; 


MHS; 

1) 

ADMD  names; 

2) 

PRMD  names; 

3) 

Organization  names; 

4) 

Encoded  information  types; 

5) 

Extended  body  part  types; 

6) 

Extensions; 

7) 

etc.; 

g)  Object  Identifier  values; 

h)  ASN.1  modules; 

i)  Directory; 

1)  Relative  distinguished  names; 
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2)  Attribute  types; 

3)  Attribute  syntaxes; 

4)  Object  classes; 

5)  Encryption  algorithms; 

6)  etc.; 

j)  VT; 

1)  Profiles; 

2)  Reference  information  objects; 

3)  etc.; 

k)  Network  management  objects; 
I)  Network  layer  addresses; 
m)  System  titles; 
n)  FTAM; 

1)  Document  types; 

2)  Constraint  sets; 

3)  etc.; 

o)  etc. 

The  OIW  Registration  Authority  shall  only  administer  information  objects  created  by  the  OIW  Agreements 
Document  that  are  identified  by  the  ASN.1  type  OBJECT  IDENTIFIER.  Figure  1  illustrates  the  structure  of 
the  object  identifier  component  value  for  OIW. 
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(  iso  identif ied-organization    oiw  (14)  ) 
iso(l) 

identif ied-organization( 3 ) 

oiw( 14 ) 

Figure  1  -  Structure  of  Object  Identifier  for  OIW. 
As  an  example  figure  2  shows  the  object  identifier  component  value  for  an  example  object. 


(  iso    identif ied-organization  oiw(14)  rasig(13) 

example ( 0 ) } 

iso(l) 

identif ied-organization( 3 ) 

rasig(13) 

example (10) 

Figure  2  -  Structure  of  an  Object  Identifier  for  an  Example  Object  for  the  Registration  Authority  BIG 

of  OIW. 

The  ISO  6523  Registration  Authority  has  assigned  an  International  Code  Designator  (ICD)  value  of  14  to 
OIW,  and  OIW  has  assigned  a  unique  object  identifier  component  value  to  each  SIG.  The  assigned  object 
ID  values  for  the  OIW  and  for  each  SIG  are  in  Annex  A.  The  assignment  of  values  below  each  SIG  in  the 
object  identifier  tree  is  the  responsibility  of  that  SIG. 


4     Registration  Procedures  for  Object  Identifiers 

This  clause  specifies  the  responsibilities  of  each  SIG  and  the  procedures  to  be  followed  for  the  registration 
of  information  objects,  and  submission  to  the  OIW  Plenary. 

When  an  OIW  SIG  defines  an  information  object  the  SIG  shall  register  the  object  identifier.  The  registered 
value  shall  be  incorporated  into  the  appropriate  OIW  Agreements  Document  as  a  result  of  a  positive  ballot 
response  of  the  OIW  Plenary. 

4.1      SIG  Registration  Authorization 

An  OIW  SIG  is  authorized  by  its  charter  and  the  scope  of  its  work  to  submit  a  registration  request  to  the 
OIW  Plenary. 
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4.2      SIG  Registration  Authority  Function  and  Duties 

The  SIG  Chair  is  responsible  for  the  assignment,  recording  and  maintenance  of  the  SIG's  registered  objects. 
The  SIG  Chair  may  appoint  a  specific  person  to  carry  out  the  SIG  duties  and  responsibilities. 


4.3      Requirements  for  Information  Object  Registration 


4.3.1       Assignment  of  Object  Identifier  Component  Values 

Each  SIG  shall  register  an  object  identifier  component  value  for  each  object's  technical  definition.  The 
NameAndNumberForm  of  the  ObjIdComponent  specified  in  ISO  8824/CCITT  X.208  is  used  exclusively.  This 
form  comprises  an  ASN.1  identifier  and,  significantly,  a  NumberForm. 

It  is  suggested  that  the  SIG  assign  a  monotonically  increasing  integer  to  the  NumberForm  at  any  given  level. 
To  the  significant  root  the  SIG  shall  add  a  assigned  object  identifier  component  value  that  shall  be  unique. 
An  example  of  an  object  identifier  created  by  the  RASIG  is  shown  as  follows: 

{iso(l)identified-organization(3)  oiw(14)  rasig(13)  example(O)} 

Here  rasig  is  the  SIG  identifier  and  13  is  the  NumberForm  assigned  by  the  OIW  Registration  Authority  (see 
Annex  A);  example  is  the  identifier  and  0  is  the  NumberForm  assigned  by  the  RASIG. 


4.3.2       Proposal  of  Object  and  Identifier  to  Plenary 

Registration  of  an  object  identifier  and  its  definition  is  proposed  by  inclusion  of  the  object  identifier  and  its 
definition  in  the  OIW  "Working  Implementation  Agreements"  document. 


4.3.3       Completion  of  Registration  Procedure 

Registration  of  an  object  identifier  and  its  definition  is  completed  upon  Plenary  vote  to  move  "Working 
Implementation  Agreements"  text  which  contains  the  object  identifier  and  its  definition  to  the  "Stable 
Implementation  Agreements"  document. 


4.3.4       Changes  and  Revisions  to  the  Information  Object  Registration 

Neither  the  technical  definition  nor  the  object  identifier  shall  be  changed  or  modified  after  registration  i.e., 
after  the  definitions  and  their  identifiers  have  been  voted  into  the  "Stable  Implementation  Agreements" 
document. 


5 


PART  6  -  REGISTRATION  AUTHORITY  PROCEDURES  FOR  THE  OSI  IMPLEMENTORS 
WORKSHOP  (OIW)  December  1990  (Stable) 


4.4      Register  Index 

Each  SIG  shall  maintain  an  index  of  object  identifiers  that  point  to  the  technical  definitions  of  the  respective 
objects  in  the  OIW  Agreements  Document.  The  index  shall  appear  in  the  appropriate  part  annexes  of  the 
OIW  Agreements  Document. 

Index  entry  example: 

Object  Identifier  Reference 

iso  identified-organization  4.3.1 
oiw(14)  rasig(13)  example(O) 
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Annex  A  (normative) 

Assignments  to  Workshop  Organizations 


Identifier 

Value 

oiw 

14 

(Assigned  to  OIW  by 

ISO  6523  RA) 

llsig 

1 

(Assigned  to  SIG  by  OIW) 

nmsig 

2 

secsig 

3 

tpsig 

4 

f tamsig 

5 

mhsig 

6 

dssig 

7 

ulsig 

8 

rdasig 

9 

nunssig 

10 

odasig 

11 

vtsig 

12 

rasig 

13 
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Annex  B  (normative) 

Status  of  1987  and  1988  Ad-hoc  Object  Identifiers 

In  the  1987  and  1988  versions  of  the  Stable  Implementation  Agreements,  a  number  of  OlW-specified 
information  objects  are  assigned  object  identifiers. 

OSI  requires  names  and  addresses,  e.g.,  object  identifiers,  be  globally  unambiguous.  This  chapter  specifies 
object  identifier  component  values  which  are  globally  unambiguous.  Other  chapters  in  this  document 
specify  the  correct  object  identifiers  to  be  used  when  referencing  OlW-specified  information  objects. 

The  use  of  the  1987  and  1988  OlW-specified  object  identifiers  is  deprecated.  Newly  defined  objects  shall 
use  the  new  OIW  Identifier. 

'■        '  ''° 
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NOTE  -  The  classification  schema  used  in  this  chapter  (see  table  7)  pre-dated  TR  10  000  and  was  the 
basis  of  extensive  harmonization,  as  such:  No  attempt  will  be  made  to  align  this  chapter  with  TR  10  000. 

Editor's  Note  -  Several  errata  items  were  approved  at  the  March  1991  OlW  Pleanry.  dealing  with  (a)  a 
pjewsrequirement  for  the  generation  of  domain-defined  attributes,  and  (b)  a  relaxation  of  requirement  iot-W. 
10  Of  the  EIT  to  be  set  (recommendation  for  ODA  transfer).  Text  j$  found  in  the  aligned  sectiort  of  the 
VS/(»feing  Document. 


0  Introduction 

This  is  an  implementation  agreement  developed  by  the  Implementor's  Workshop  sponsored  by  the  U.S. 
National  Institute  of  Standards  and  Technology  to  promote  the  useful  exchange  of  data  between 
devices  manufactured  by  different  vendors.  This  agreement  is  based  on,  and  employs  protocols 
developed  in  accord  with,  the  OSI  Reference  Model.  While  this  agreement  introduces  no  new  protocols, 
it  eliminates  ambiguities  in  interpretations. 

This  is  an  implementation  agreement  for  a  Message  Handling  System  (MHS)  based  on  the  X.400-series 
of  Recommendations  (1984)  and  Version  5  of  the  X.400  Series  Implementor's  Guide  from  the  CCITT.  It  is 
recommended  that  product  vendors  consult  later  versions  of  this  guide.  Figure  1  displays  the  layered 
structure  of  this  agreement. 

This  agreement  can  be  used  over  any  Transport  protocol  class.  In  particular,  this  MHS  agreement  can 
be  used  over  the  Transport  protocol  class  0  used  over  CCITT  X.25,  described  in  clause  5.2  of  this 
document.  In  addition,  this  MHS  agreement  can  be  used  over  the  Transport  profiles  used  in  support  of 
MAP  (Manufacturing  Automation  Protocol)  or  TOP  (Technical  and  Office  Protocols).  Note  that  the  MAP 
or  TOP  environment  must  support  the  reduced  Basic  Activity  Subset  (BAS)  as  defined  in  X.410. 

The  UAs  and  MTAs  require  access  to  directory  and  routing  services.  A  Directory  Service  is  to  be 
provided  for  each  (vendor-specific)  domain.  Except  insofar  as  they  must  be  capable  of  providing 
addressing  and  routing  described  hereunder,  these  services  and  associated  protocols  are  not  described 
by  this  agreement. 


User  Agent  Layer 

CCITT  X.420 

Message  Transfer  Agent  Layer 

CCITT  X.411 

Reliable  Transfer  Service  Layer 

CCITT  X.410 

Presentation  Layer 

CCITT  X.410  Sec.  4.2 

Session  Layer 

See  clause  5.9 

Figure  1  -  The  layered  structure  of  this  implementation  agreement. 
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1  Scope 

This  agreement  applies  to  Private  Management  Domains  (PRMDs)  and  Administration  Management 
Domains  (ADMDs).  Four  boundary  interfaces  are  specified: 

a)  PRMDtoPRMD. 

b)  PRMDtoADMD, 

c)  ADMD  to  ADMD,  and 

d)  MTA  to  MTA  (witfiin  a  PRMD,  e.g.,  for  MTAs  from  different  vendors). 

In  case  A,  tfie  PRMDs  do  not  make  use  of  MHS  services  provided  by  an  ADMD.  In  cases  B  and  C,  UAs 
associated  witii  an  ADMD  can  be  tfie  source  or  destination  for  messages.  Furtliermore,  in  cases  A  and 
B,  a  PRMD  can  serve  as  a  relay  between  MDs,  and  in  cases  B  and  C  an  ADMD  can  serve  as  a  relay 
between  MDs.  Figure  2  illustrates  the  interfaces  to  which  the  agreement  applies. 

X.400  protocols  other  than  the  Message  Transfer  Protocol  (P1)  and  the  Interpersonal  Messaging 
Protocol  (P2)  are  beyond  the  scope  of  this  agreement.  Issues  arising  from  the  use  of  other  protocols  or 
relating  to  P1  components  in  support  of  other  protocols  are  outside  the  scope  of  this  document.  This 
agreement  describes  the  minimum  level  of  services  provided  at  each  interface  shown  in  figure  2. 
Provision  for  the  use  of  the  remaining  services  defined  in  the  X.400  Series  of  Recommendations  is 
outside  the  scope  of  this  document. 

With  the  exception  of  intra  domain  connections,  this  agreement  does  not  cover  message  exchange 
between  communicating  entities  within  a  domain  even  if  these  entities  communicate  via  P1  or  P2. 
Bilateral  agreements  between  domains  may  be  implemented  in  addition  to  the  requirements  stated  in 
this  document.  Conformance  to  this  agreement  requires  the  ability  to  exchange  messages  without 
use  of  bilateral  agreements. 
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PRMD  =  Private  Management  Domain 

ADMD  =  Administration  Management  Domain 
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MTA 
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 D 

MTA 

B 

PRMD 


I 
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PRMD 
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ADMD 
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Figure  2  -  This  agreement  applies  to  the  interface  between:  (A)  PRIVID  and  PRMD;  (B)  PRMD  and 
ADMD;  (C)  ADMD  and  ADMD;  and  (D)  MTA  and  MTA. 
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Syntax  and  Notation. 

CCITT  Recommendation  X.410,  (Red  Book,  1984),  Message  Handling  Systems:  Remote  Operations  and 
Reliable  Transfer  Server. 

CCITT  Recommendation  X.411,  (Red  Book,  1984),  Message  Handling  Systems:  Message  Transfer  Layer. 

CCITT  Recommendation  X.420,  (Red  Book,  1984),  MessageHandling  Systems:  Interpersonal  Messaging 
User  Agent  l_ayer. 

CCITT  Recommendation  X.430,  (Red  Book,  1984),  Message  Handling  Systems:  Access  Protocol  for 
Teletex  Terminals. 
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3  Status 

This  version  of  ttie  X.400  based  Message  Handling  System  implementation  agreements  was  completed 
on  December  16,  1988.  No  further  enhancements  will  be  made  to  this  version.  See  the  next 
clause-Errata. 


4  Errata 

5  PRMD  to  PRMD 
5.1  Introduction 


This  clause  is  limited  in  scope  to  issues  arising  from  the  direct  connection  (interface  A  in  figure  2)  of  two 
PRMDs.  "Direct"  means  that  no  ADMD  or  relaying  PRMD  provides  MHS  services  to  facilitate  message 
interchange.  "Direct"  does  not  exclude  those  instances  for  which  Administrations  happen  to  be  ADMDs 
but  are  not  providing  X.400  services,  that  is,  they  are  used  only  to  provide  lower  layer  services  such  as 
X.25.  Figure  3  schematically  represents  the  scope  of  this  clause. 

These  issues  relate  to  the  use  of  the  UAL  (User  Agent  Layer)  and  MTL  (Message  Transfer  Layer) 
services,  protocol  elements,  recommended  practices  and  constraints.  In  particular,  this  clause  addresses 
the  PI  and  P2  protocols  and  their  related  services  in  a  direct  connection  environment.  This  clause 
describes  the  minimum  level  of  services  provided  by  a  PRMD.  Provision  for  the  use  of  the  remaining 
services  defined  in  the  X.400  Series  of  Recommendations  is  beyond  the  scope  of  this  clause. 


Private  Domain  X 


UA 


MTA 


/ 

\ 

the 

;remainder  o£  : 

Domain 

X 

NETWORK 

P2 
PI 


Private  Domain  Y 


UA 


MTA 


<— I 


the 

remainder  ofi: 
Domain  Y 
NETWORK 


Figure  3  -  Interconnection  of  private  domains. 
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5.2      Service  Elements  and  Optional  User  Facilities 

This  clause  identifies  tliose  service  elements  and  optional  user  facilities  that  nnust  be  provided  in  support 
of  P1  and  P2. 


The  classification  of  UA  and  MT-Service  elements  is  used  to  define  characteristics  of  equipment. 
Equipment  can  claim  SUPPORT  or  NON-SUPPORT  of  a  Service;  in  the  case  of  UA-service  elements,  a 
separate  classification  is  given  for  Origination  and  Reception. 

The  service  provider  is  defined  as  the  entity  providing  the  service,  in  this  case,  the  MTL  or  the  UAL.  The 
service  user  is  either  the  MHS  user  or  the  UAL.  The  classification  of  provider  and  user  relates  to  the 
sublayer  for  which  the  service  element  is  defined. 


Support  means: 

a)  The  service  provider  makes  the  service  element  available  to  the  service  user,  and 

b)  The  service  user  gives  adequate  support  to  the  MHS  to  invoke  the  service  element  or  makes 
information  associated  with  the  service  element  available. 

Support  for  Origination  means  that: 

a)  The  service  provider  makes  the  service  element  available  to  the  service  user  for  invocation, 
and 

b)  The  service  user  gives  adequate  support  to  the  end  user  of  the  MHS  to  invoke  the  service 
element. 

Support  for  Reception  means  that: 

a)  The  service  provider  makes  information  associated  with  the  service  element  available  to  the 
service  user. 

NOTE  -  A  UA-  or  MT-service  element  can  carry  information  from  originator  to  recipient  only  if: 

b)  the  service  element  is  available  to  the  originator, 

c)  the  service  element  is  available  to  the  recipient,  and 

d)  all  intermediate  steps  carry  the  information. 


5.2.1 


Classification  of  Support  for  Services 


5.2.1.1 


Support  (S) 
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5.2.1.2         Non  Support  (N) 

This  means  that  the  service  provider  is  not  required  to  make  the  service  element  available  to  the  service 
user.  However,  the  service  provider  should  not  regard  the  occurrence  of  the  corresponding  protocol 
elements  as  an  error  and  should  be  able  to  relay  such  elements.  Implementations  making  a  profile 
available  should  indicate  deviations  (additions  or  deletions)  with  respect  to  the  requirement  in  the  profile. 


5.2.1.3  Not  Used  (N/U) 

This  means  that  although  the  Recommendation  allows  this  service  element,  this  profile  does  not  use  it. 


5.2.1.4        Not  Applicable  (N/A) 

This  means  that  this  service  element  does  not  apply  in  this  particular  case  (for  originator  or  recipient). 


5.2.2       Summary  of  Supported  Services 

Within  a  PRMD,  a  User  Agent  must  support  all  P2  BASIC  IPM  Services  (X.400)  and  all  P2  ESSENTIAL 
IPM  Optional  user  facilities  (X.401)  subject  to  the  qualifiers  listed  in  annex  A. 

Within  a  PRMD,  a  MTA  must  support  all  BASIC  MT  Services  (X.400)  and  all  ESSENTIAL  MT  optional 
user  facilities  (X.401)  subject  to  the  qualifiers  listed  in  annex  A. 

No  support  is  required  of  the  additional  optional  user  facilities  of  X.401. 


5.2.3       MT  Service  Elements  and  Optional  User  Facilities 
Tables  1  through  3  show  the  Message  Transfer  (MT)  service  elements  and  optional  user  facilities. 

Table  1  -  Basic  MT  Service  Elements 


Support  (S)  or 


Service  Elements  Non-support  (N) 


Access  Management  N/U 

Content  Type  Indication  S 

Converted  Indication  S 

Delivery  Time  Stamp  Indication  S 

Message  Identification  S 

Non-delivery  Notification  S 

Original  Encoded  Information  Types  Indication  S 

Registered  Encoded  Information  Types  N/U 

Submission  Time  Stamp  Indication  S 


Notes 

1    Not  applicable  to  co-resident  UA  and  MTA. 
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Table  2  -  MT  Optional  User  Facilities  Provided  to  the  UA-Selectable  on  a  Per-Message  Basis 


Support  (S)  or 

MT  Optional  User  Facilities  Categorization    Non-support  (N) 


Alternate  Recipient  Allowed 

E 

S 

Conversion  Prohibition 

E 

Deferred  Delivery 

E 

k 

Deferred  Delivery  Cancellation 

E 

N^ 

Delivery  Notification 

E 

Disclosure  of  Other  Recipients 

E 

^3 

Explicit  Conversion 

A 

N 

Grade  of  Delivery  Selection 

E 

S 

Multi-destination  Delivery 

E 

S 

Prevention  of  Non-delivery  Notification 

A 

Probe 

E 

N* 

Return  of  Contents 

A 

N 

Legend 

E:    Essential  optional  user  facility. 
A:    Additional  optional  user  facility. 


Notes 

2  A  local  facility  subject  to  qualifiers  in  annex  A. 

3  Support  not  required  for  an  originating  MT  user;  support  must  be 
provided  for  recipient  MT  users. 

4  Subject  to  qualifiers  in  annex  A. 


Table  3  -  MT  Optional  User  Facilities  Provided  to  the  UA  Agreed  for  Any  Contractual  Period  of 

Time 


MT  Optional  User  Facilities  Categorization 

Support  (S)  or 
Non-Support  (N) 

Alternate  Recipient  Assignment  A 
Hold  for  Delivery  A 
Implicit  Conversion  A 

N 

N/U 
N 

Legend 

A:    Additional  optional  user  facility. 

5.2.4       IPM  Service  Elements  and  Optional  User  Facilities 

Tables  4  through  6  show  the  iPM  service  elements  and  optional  user  facilities. 
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Table  4  -  Basic  IPM  service  elements 


Or  i  ainat  ion 

Reception 

Service  Elements 

by  UAs 

by  UAs 

Access  Management 

N/u5 

N/U^ 

Content  Type  Indication 

S 

S 

Converted  Indication 

N/A 

S 

Delivery  Time  Steunp  Indication 

N/A 

s 

Message  Identification 

S 

s 

Non-delivery  Notification 

S 

N/A 

Original  Encoded  Information 

s 

S 

Types  Indication 

Registered  Encoded  Information  Types  N/A 

n/a5 

Submission  Time  Stamp  Indication 

s 

s 

IP-message  Identification 

s 

s 

Typed  Body 

s 

s 

Notes 

5    Does  not  apply  to  co-resident 

UA  and  MTA. 

Table  5  -  IPM  Optional  Facilities  Agreed  for  a  Contractual  Period  of  Time 


Support  (S)  or 

Service  Elements  Categorization 

Non-Support  (N) 

Alternate  Recipient  Assignment  A 

N 

Hold  for  Delivery  A 

N 

Implicit  Conversion  A 

N 
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Table  6  -  IPM  Optional  User  Facilities  Selectable  on  a  Per-Message  Basis 


Origination 

IPM  Optional  User  Facilities                       by  UAs 

Reception 
by  UAs 

Alternate  Recipient  Allowed 

A 

(N) 

A 

(N) 

Authorizing    Users  Indication 

A 

(N) 

E 

(S) 

Auto-forwarded  Indication 

A 

(N) 

E 

(S) 

Blind  Copy  Recipient  Indication 

A 

(N) 

E 

(S) 

Body  Part  Encryption  Indication 

A 

(N) 

E 

(S) 

Conversion  Prohibition 

E 

(S) 

E 

(S) 

Cross-referencing  Indication 

A 

E 

(S) 

Deferred  Delivery 

E 

(N)° 

N/A 

Deferred  Delivery  Cancellation 

A 

(N/U)^ 

N/A 

Delivery  Notification 

E 

(S) 

N/A 

Disclosure  of  Other  Recipients 

A 

(N) 

E 

(S) 

Expiry  Date  Indication 

A 

(N) 

E 

(S) 

Explicit  Conversion 

A 

(N) 

N/A 

Forwarded  IP— message  Indication 

A 

(N) 

E 

(S) 

Grade  of  Delivery  Selection 

E 

(S) 

E 

(S) 

Importance  Indication 

A 

(N) 

E 

(S) 

Mult i -destination  Delivery 

E 

(S) 

N/A 

Multi-part  Body 

A 

(N) 

E 

(S) 

Non-receipt  Notification 

A 

(N) 

A 

(N) 

Obsoleting  Indication 

A 

(N) 

E 

(S) 

Originator  Indication 

E 

(S) 

E 

(S) 

Prevention  of  Non-delivery  Notification 

A 

(N) 

N/A 

Primary  and  Copy  Recipients  Indication 

E 

(S) 

E 

(S) 

Probe 

A 

(N) 

N/A 

Receipt  Notification 

A 

(N) 

A 

(N) 

Reply  Request  Indication 

A 

(N) 

E 

(S) 

Replying  IP-message  Indication 

E 

(S) 

E 

(S) 

Return  of  Contents 

A 

(N) 

N/A 

Sensitivity  Indication 

A 

(N) 

E 

(S) 

Subject  Indication 

E 

(S) 

E 

(S) 

Notes 

6    A  local  facility  subject  to  qualifiers  in  annex 

A, 

5.3      X.400  Protocol  Definitions 

This  clause  reflects  the  agreements  of  the  NIST/OSI  Workshop  regarding  P1  and  P2  protocol  elements. 

5.3.1       Protocol  Classification 

The  protocol  classifications  are  defined  in  table  7. 


9 


Part  7:  1984  Message  Handling  Systems 

Table  7  -  Protocol  Classifications 


December  1990  (Stable) 


1)  UNSUPPORTED  =  X 

These  elements  may  be  generated,  but  no  specific  processing  should 
be  expected  in  a  relaying  or  delivering  domain.  A  relaying  domain 
must  at  least  relay  the  semantics  of  the  element.  The  absence  of 
these  elements  should  not  be  assumed,  in  a  relaying  or  delivering 
domain,  to  convey  any  significance. 

2)  SUPPORTED  =  H 

These  elements  may  be  generated.  However,  implementations  are  not 
required  to  be  able  to  generate  these  elements.  Appropriate 
actions  shall  be  taken  in  a  relaying  or  delivering  domain. 

3)  GENERATABLE  =  G 

Implementations  must  be  able  to  generate  and  handle  these  protocol 
elements,  although  they  are  not  necessarily  present  in  all 
messages  generated  by  implementations  of  this  profile. 
Appropriate  actions  shall  be  taken  in  a  relaying  or  delivering 
domain. 

4)  REQUIRED  =  R 

Implementations  of  this  profile  must  always  generate  this  protocol 
element.  However,  its  absence  cannot  be  regarded  as  a  protocol 
violation  as  other  MHS  implementations  may  not  require  this 
protocol  element.  Appropriate  actions  shall  be  taken  in  a 
relaying  or  delivering  domain. 

5)  MANDATORY  =  M 

This  must  occur  in  each  message  as  per  X.411  or  X.420  as 
appropriate;  absence  is  a  protocol  violation.  Appropriate  actions 
shall  be  taken  in  a  relaying  or  delivering  domain. 


5.3.2       General  Statements  on  Pragmatic  Constraints 

Where  a  protocol  element  is  defined  as  a  choice  of  Numeric  String  and  Printable  String  (i.e., 
Administration  Domain  Name  and  Private  Domain  Identifier),  then  a  numeric  value  encoded  as  a 
printable  string  is  equivalent  to  the  same  value  encoded  as  a  numeric  string.  This  does  not  apply  to  the 
Country  Name  protocol  element. 

The  maximum  number  of  recipients  in  a  single  MPDU  is  32K  - 1  (that  is,  32767).  However,  no  individual 
limits  on  the  number  of  occurrences  (recipients)  are  placed  on  the  following  protocol  elements: 
Authorizing  Users,  Primary  Recipients,  Copy  Recipients,  Blind  Copy  Recipients,  Obsoletes  and  Cross 
References.  Additionally,  there  is  no  limit  on  the  number  of  Reply  to  Users.  This  is  a  local  matter  for  the 
originating  system. 

Use  of  strings.  A  Printable  String  is  defined  in  terms  of  the  number  of  characters,  which  is  the  same 
number  of  octets.  For  T.61  strings  the  number  of  octets  is  twice  the  number  of  characters  specified. 

The  ability  to  generate  maximum  size  elements  is  not  required,  with  the  exception  of  the  component 
fields  in  the  Standard  Attribute  List,  in  which  case  it  is  required. 
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5.3.3  MPDU  Size 

The  following  agreements  govern  the  size  of  MPDUs: 

a)  All  MTAEs  must  support  at  least  one  MPDU  of  at  least  2  megabyte,  and 

b)  The  size  of  the  largest  MPDU  supported  by  a  UAE  is  a  local  matter. 

5.3.4  PI  Protocol  Elements 

Table  8  contains  Protocol  Elements  and  their  classes. 
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Table  8  -  Pi  Protocol  Elements 


Class 

MPDU 

Ticd-VTDTMI 

G 

ue  J.  1  ve  r  yKepO  r  tfiirUU 

G 

ProbeMPDU 

H 

UserMDPU 

UMPDUEnvelope 

M 

UMPDUContent 

M 

UMPDUEn ve 1 ope 

MPDUIdentif ier 

M 

originator  ORname 

M 

originalEncodedlnformationTypes 

G 

±1.   Liiis  LiexQ  IS  aos&iix.  f   X.1IQH  ^n6 

jCiiicoaeu  xnLorinaT,ion  lype  is 

"unspecified. " 

ContentType 

M 

UAContentID 

H 

Maximum  length  =  16  characters. 

Priority 

G 

PerMessageFlag 

G 

Maximum  length  =  2  octets. 

def erredDelivery 

V 
A 

PerDomainBilaterallnfo 

X 

pivj               Oil  iiumiJ€L  QL  occurr6nc6s. 

Recipientlnfo 

M 

ences .  More  severe  limitations  are 

by  bilateral  agreement. 

Tracelnformation 

M 

UMPDUContent 

M 

MPDUIdentif ier 

GlobalDomainldentif ier 

M 

lASString 

M 

Maximum  length  =  32  characters, 

graphical  subset  only.    Refer  to 

T.50  for  clarification  of  graphical 

PerMessageFlag 

subset . 

discloseRecipients 

H 

conversionProhibited 

G 

alternateRecipientAllowed 

H 

contentReturnRequest 

X 
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Table  8  -  PI  Protocol  Elements  (continued) 


1 

Element 

Class 

Restrictions  and  Conunents 

PerDomainBilaterallnfo 

Count  r  vName 

H 

Maximum  lenath  =  3  characters 

Adm i n i s t r a t i onDoma i nName 

M 

Maximum  length  =  16  characters. 

Bilaterallnfo 

M 

Maximxun  depth  =  8;  maximum 

length  =  1024  octets 

(including  encoding). 

Recipient Info 

recipient 

M 

Ext  ens  i  onl  dent  i  f  i  e  r 

M 

Maximum  value  =  32K  -  1  (32767). 

perRecipientFlag 

M 

Maximum  length  =  2  octets. 

ExplicitConversion 

X 

ResponsibilityFlag 

M 

ReportRequest 

M 

UserReportRequest 

M 

Tracelnformation 

Reference  should  be  made  to 

Version  5  of  the  X.400  Imple- 

mentor's  Guide  for  information 

GlobalDomainldentifier 

M 

related  to  Trace  sequencing. 

Doma i nSuppl i ed I nf o 

M 

DomainSu'D'Dl  i  edinf  o 

arrival 

M 

deferred 

X 

action 

M 

0=relayed  (value) 

G 

l=rerouted  (value) 

H 

Rerouting  is  not  required. 

converted 

H 

previous 

H 

ORName 

See  clause  5.3.5 

Encodedinf ormat  ionTypes 

bit  string 

M 

Delivery  can  only  occur  if  match 

is  made  with  Registered  Encoded 

Information  Types.  Individual 

vendors  may  impose  limits. 

Maximum  length  =  4  octets. 

G3NonBasicParameters 

X 

TeletexNonBasicParameters 

X 

Presentat  ionCapabi 1 i  t  i  es 

X 
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Table  8  -  PI  Protocol  Elements  (continued) 


Element 

Class 

Restrictions  and  Comments 

De 1 i  ve  r yRepo r  t MPDU 

De liver  yRepo r  t En ve 1 ope 

M 

Deli veryReportContent 

M 

Deliver yReport En ve 1 ope 

reoort 

M 

originator 

M 

Traceinf ormat  ion 

M 

Deli veryReportContent 

original 

M 

intermediate 

6 

See  comment  at  end  of  table. 

UAContentID 

G 

ReportedRecipientlnfo 

M 

Maximum  number  =  32K  -  1 

occurrences . 

returned 

H 

Can  only  be  issued  if  specifically 

requested  in  the  originating 

message. 

billinglnformation 

X 

Maximum  depth  =  8;  maximum 

length  =  1024  octets  (including 

encoding) . 

ReportedRecipientlnfo 

recipient 

M 

Extensions Identifier 

M 

PerRecipientFlag 

M 

Las tTraceInf ormat ion 

M 

intendedRecipient 

Supplementaryinf ormat ion 

X 

Maximum  length  =  64  characters. 

Value  is  pending  verification  by 

the  CCITT  SG  VIII  or  XI. 

LastTraceInf ormat ion 

arrival 

M 

converted 

G 

Report 

M 

14 


Part  7:  1984  Message  Handling  Systems  June  1991  (Stable) 


Table  8  -  PI  Protocol  Elements  (concluded) 


Element 

Class 

Restrictions  and  Comments 

Report 

Deliveredlnfo 
Nondeliveredlnfo 

Deliveredlnfo 
delivery 
typeofUA 

G 
G 

M 
R 

Generated  if  delivery  is  reported. 
Generated  if  failure  to  deliver 
is  reported. 

This  element  must  be  generated  with 
a  PRIVATE  value  by  PRMDs, 

NonDeliveredlnfo 
ReasonCode 
D  i  agnos  t  i  cCode 

M 
H 

Whenever  possible,  use  a  meaningful 
□ 1 agnos uxc  coae. 

ProbeEnvelope 
probe 
originator 
Content Type 
UAContentID 
original 

M 
M 
M 
H 
G 

Maximum  length  =  16  characters. 
If  this  field  is  absent,  then  the 
Encoded  Information  Type  is 
"unspecified. " 

Tracelnformation 

M 

PerMessageFlag 

G 

contentLength 
PerDomainBi later allnfo 
Recipientlnfo 

GlobalDoma i nident i £ i e r 
Count ryName 

Admi  ni  s  t  r  a t  i  onDoma  i  nName 

(4) 

H 
X 
M 

M 
M 

Maximum  number  =  32K  -  1 
occurrences. 

Maximum  length  =  3  characters. 
Maximum  length  =  16  characters  or 
digits . 

PrivateDomainldentif ier 

R 

Maximum  length  =  16  characters  or 
digits.     This  element  must  be 
generated  by  PRMDs. 

End 

of  Definitions 

Notes 

Comment  on  intermediate  Tracelnformation  in  the  DeliveryReportContent  in 
table  8:    Audit  and  confirmed  reports  should  not  be  requested    by  other 
than  the  originating  domain  for  two  reasons.  First,  the  return  path  of 
the  report  may  be  different  from  the  path  taken  by  the  original  message, 
and  it  may  exclude  the  domain  that  added  the  request  for  audit  and 
confirmed  to  the  message.  Second,  if  the  return  path  is  different  from 
the  path  of  the  original  message,  the  originating  domain  would  receive 
intermediate  trace  information  that  it  did  not  request. 
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5.3.5       ORName  Protocol  Elements 

Only  form  1  variant  1  0/R  names  are  supported. 
Table  9  contains  ORName  protocol  elements. 

These  agreements  interpret  1984  X.400  clause  3.4  to  mean  that  the  attributes  in  the  ORName  in  the 
MPDU  must  identify  exactly  one  UA.  and  that  all  the  values  for  the  attributes  specified  in  the  ORName 
must  be  identical  to  the  values  of  the  corresponding  attributes  associated  with  the  recipient  UA. 
Underspecified  names  that  are  unique  are  deliverable. 

Overspecified  ORNames,  ORNames  with  mismatching  fields,  and  ambiguous  names  are  to  be  non- 
delivered  or  sent  to  the  alternate  recipient  as  appropriate. 


Table  9  -  ORName  Protocol  Elements 


Element 

Class 

Restrictions  and  Comments 

ORName 

StandardAttributeList 

M 

DomainDef inedAttributeList 

StandardAttributeList  (1) 

Count ryName 

R 

As  defined  in  X.411,  Maximum 

length  =  3  characters. 

AdministrationDomainNeune  (4) 

R 

Maximum  length  =  16  characters 

or  digits. 

Y 
A 

naximum  xeng^n  —  aigirs. 

TerminallD 

X 

Maximim  length  =  24  characters. 

PrivateDomainName  (2) 

6 

Maximum  length  =  16  characters. 

OrganizationNeune  (2) 

6 

Maximum  length  =  64  characters. 

Un  i  queUAI dentifier 

X 

Maximum  length  =  32  digits. 

PersonalName 

G 

Maximum  length  of  values  of  sub- 

elements  =  64  characters. 

Note:    The  possibility  that  this 

value  may  be  reduced  to  40 

characters  is  for  further 

study  by  the  CCITT. 

OrganizationalUnit  (3) 

G 

Maximum  length  =32  characters  per 

occurrence.    A  maximum  of  four 

occurrences  are  allowed. 

DomainDef inedAttributeList  (5) 

Maximum  =  4  occurrences. 

type 

M 

Maximum  length  =  8  characters. 

value 

M 

Maximum  length  =  128  characters. 

PersonalName 

surName 

M 

Maximum  length  =40  characters. 

givenName 

G 

Maximum  length  =  16  characters. 

initials 

G 

Maximum  length  =    5  characters; 

excluding  surname  initial  and 

generat  ionQual i  f  ier 

punctuation  and  spaces. 

G 

Maximum  length  =  3  characters. 
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Table  9  -  ORName  Protocol  Elements  (concluded) 


Notes: 

1  The  following  apply  for  comparison  of  the  Standard  Attributes  of  an 
0/R  Name: 

a)  Lower  case  is  interpreted  as  upper  case  (for  IA5). 

b)  Multiple  spaces  may  be  interpreted  as  a  single  space.  Originating 
domains  shall  only  transmit  single  significant  spaces.  If  multiple 
spaces  are  transmitted,  non-delivery  may  occur. 

2  At  least  one  of  these  must  be  supplied. 

3  These  should  be  sent  in  descending  sequence,  from  the  most  significant 
<Organizational  Unit>  (highest  in  organization  hierarchy)  to  the  least 
significant.  Only  those  specified  should  be  sent.  (That  is,  an 
unspecified  <Organizational    Unit>  should  not  be  sent  along  as  a  field 
of  [null]  content,  nor  zero  length,  etc.) 

4  This  attribute  shall  contain  one  space  in  all  ORNames  of  messages 
originated  in  a  PRMD  that  is  not  connected  to  an  ADMD,  and  in  ORNames 
of  recipients  reachable  only  through  a  PRMD;  otherwise,  this  attribute 
shall  contain  an  appropriate  ADMD  ncune. 

5  Some  existing  systems  which  will  be  accessed  via  an  X.400  service 
(whether  directly  connected  using  X.400  protocols  or  otherwise)  may 
require  the  provision  of  addressing  attributes  which  are  not  adequately 
supported  by  Standard  Attributes  as  defined  in  these  Agreements.  In 
such  cases.  Domain  Defined  Attributes  are  an  acceptable  means  of 
carrying  additional  addressing  information.  Failure  to  support  the 
specification  and  relaying  of  DDAs  may  prevent  successful  interworking 
with  such  existing  systems  until  such  time  as  all  systems  are  capable 
of  relaying  and  delivery  using  only  the  Standard  Attribute  list. 
Specific  recommendations  on  the  use  of  DDAs  for  particular  applications 
are  in  the  Recommended  Practices,  annex  B. 


5.3.6       P2  Protocol  Profile  (Based  on  [X.420]) 

Tables  10  and  11  classify  the  support  for  the  P2  protocol  elements  required  by  this  profile.  The  tables 
give  restrictions  and  comments  in  addition  to  X.420. 

Restriction  on  length  is  one  of  the  types  of  restrictions.  The  reaction  of  implementations  to  a  violation  of 
this  restriction  is  not  defined  by  this  Profile. 


5.3.6.1         P2  Protocol  -  Heading 

Table  10  specifies  the  support  for  protocol  elements  in  P2  Headings. 
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Table  10  -  P2  Heading  Protocol  Elements 


Element 

Class 

Restrictions  and  Comments 

UAPDU 

TM— TIAPDII 

G 

SR-UAPDU 

X 

IM-UAPDU 

Hp      i  na 

M 

Body 

M 

T  PMo  e  e  a  no  T 

M 

originator 

R 

author  i  z  ingUser s 

H 

primaryRecipients 

6 

At  least  one  of  primaryRecipients, 

couvReciDients 

G 

copyRecipients ,  or 
blindCopyRecipients  must  be 

b 1 i  ndCopy Rec  i  p i  en t  s 

H 

present , 

inRenlvTo 

G 

obsoletes 

H 

crossRef erences 

H 

subject 

G 

Maximum  length  =  128  T.61 
characters  (256  octets) ;the  ability 
to  generate  the  maximum  size 
subject  is  not  required. 

expiryDate 

H 

replyBy 

H 

replyToUsers 

H 

importance 

H 

Appropriate  action  is  for  further 
study. 

sensitivity 

H 

Appropriate  action  is  for  further 

study. 

autoforwarded 

H 
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Table  10  -  P2  Heading  Protocol  Elements  (continued) 


Element 

Class 

Restrictions  and  Conmients 

IPmessageld 

ORNeune 

H 

M 

ORDescriptor 

ORName 

H 

Specify  the  ORName  whenever  it  is 

possible.     See  annex  B. 

f reeformName 

H 

Maximum  length  =  64  characters, 

oraDhical  subsf^l"  onlv  fl28  octets  \ 

t  e 1 ephoneNumbe r 

H 

Maximum  length  =  32  characters. 

This  allows  for  punctuation.  It 

does  not  take  into  account  possible 

future  use  by  ISDN. 

Recipient 

ORDescriptor 

M 

report Request 

X 

replyRequest 

H 

Body 

No  limit  on  number  of  BodyParts. 

BodyPart 

G 

No  limit  on  length  of  any  BodyPart 

or  the  depth  of  ForwardedlPMessage 

BodyParts  nested.  Classification  is 

subject  to  pending  CCITT  resolution 

SR-UAPDU 

nonReceipt 

H 

receipt 

H 

reported 

M 

actualRecipient 

R 

i  nt  endedRec  i  p  i  en t 

H 

converted 

X 

NonReceipt Information 

reason 

M 

nonReceiptQualif ier 

H 

comments 

H 

Maximum  length  =  256  characters. 

returned 

H 

May  only  be  issued  if  specifically 

requested  by  originator. 
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Table  10  -  P2  Heading  Protocol  Elements  (concluded) 


Element 

Class 

Restrictions  and  Comments 

Receipt Information 

receipt 

M 

typeOfReceipt 

H 

Supplementaryinf ormat  ion 

X 

Maximum  length  =  64  characters. 

Note:     This  value  is  pending 

verification  by  the  CCITT  SG 

VIII  or  IX. 

End 

of  Definitions 

5.3.6.2        P2  Protocol  -  BodyParts 


5.3.6.2.1  BodyPart  Identifiers 

All  BodyParts  with  identifiers  in  the  range  0  up  to  and  including  16K  -1  are  legal  and  should  be  relayed. 
BodyPart  identifiers  corresponding  to  X.  121  Country  Codes  should  be  interpreted  as  described  in  Note  2 
of  figure  4. 

a)  Implementations  are  required  to  generate  and  image  lASText. 

b)  Implementations  should  specify  the  other  BodyPart  types  supported. 

c)  If  an  implementation  supports  a  particular  BodyPart  type  for  reception,  it  should  also  be  able 
to  support  that  BodyPart  type  for  reception  if  it  is  part  of  a  ForwardedlPMessage. 

d)  For  the  BodyPart  types  currently  considered,  support  for  the  protocol  elements  is  as 
j        indicated  in  table  11. 


5.3.6.2.2  Privately  Defined  BodyParts 

This  clause  describes  an  interim  means  for  identifying  privately  defined  BodyParts.  This  clause  shall  be 
replaced  in  a  future  version  taking  into  account  CCITT  recommendations  with  equivalent  functionality. 
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BodyPart  : :  =    CHOICE  { 

[0]  IMPLICIT  lASText, 
[1]  IMPLICIT  TLX, 


234]  IMPLICIT  UKBodyParts, 


310]  IMPLICIT  USABodyParts, 


} 

—  Where  UKBodyParts  and  USABodyParts  are  defined  as: 

SEQUENCE  {  BodyPart Number,  ANY  ) 
BodyPart Number  ::=  INTEGER 


Notes 

1  In  the  EncodedlnformationTypes  of  the  PI  Envelope,  the 
undefined  bit  must  be  set  when  a  message  contains  a 
privately  defined  BodyPart.  Each  UA  that  expects  such 
BodyParts  should  include  undefined  in  the  set  of 
deliverable  EncodedlnformationTypes  it  registers  with  the 
MTA. 

2  All  BodyPartNumbers  assigned  must  be  interpreted  relative 
to  the  BodyPart  in  which  they  are  used,  which  is  that 
tagged  with  the  value  [310]  for  those  defined  within  the 
United  States.  The  NIST  assigns  unique  message 
BodyPartNumbers  for  privately  defined  formats  within  the 
United  States. 

3  Refer  to  clause  12.6  for  recommendations  regarding  the 
implementaion  of  USABodyParts. 


Figure  4  -  X.409  Definition  of  Privately  Defined  BodyParts. 


5.3.6.3        92  BodyPart  Protocol  Elements 
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Table  1 1  -  P2  BodyParts 


Elements 

Class 

Restrictions  and  Conunents 

BodyPart 

lASText 

G 

TLX 

X 

Voice 

X 

G3Fax 

X 

TIFO 

X 

TTX 

X 

Videotex 

X 

Na t  i  onal lyDef  ined 

X 

Encr voted 

X 

ForwardedlPMessage 

H 

SFD 

X 

TIFl 

X 

unidentified 

,     X  ' 

lASText 

repertoi  re 

H 

For  rendition  of  lASText  see 

lASString 

M 

■  1. 

annex  C. 

TLX 

For  further  study  by  CCITT. 

Voice 

Set 

For  further  study  by  CCITT. 

BitString 

M 

G3Fax 

numberOfPages 

X 

PI .G3NonBasicParameters 

X 

SEQUENCE   (OF  BIT  STRING) 

M 

BIT  STRING 

H 

See  Note. 

PI .GSNonBasicParameters 

Support  for  individual  elements  is 

for  further  study. 

TIFO 

T.73Document 

M 

T.73ProtocolElement 

H 

See  Note. 
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Table  1 1  -  P2  BodyParts  (continued) 


Elements 

Class 

Restrictions  and  Comments 

TTX 

numberOfPages 

X 

telexCompatible 

X 

PI  .TeletexNonBasicPareiins 

X 

SEQUENCE 

M 

T61String 

H 

See  Note. 

PI  .TeletexNonBasicPareuns 

graphicCharacterSets 

X 

controlCharacterSets 

X 

pageFormats 

X 

miscTerminalCapabilities 

X 

privateUse 

X 

Videotex 

SET 

For  further  study  by  CCITT. 

VideotexString 

M 

Na t  i  onal lyDef  i  ned 

ANY 

M 

Encrypted 

SET 

For  further  study  by  CCITT. 

BIT  STRING 

M 

ForwardedlPMessage 

delivery 

H 

Del i  veryinf ormat  ion 

H 

IM-UAPDU 

M 

Deliverylnformation 

PI. Con tent Type 

M 

originator 

M 

original 

M 

PI .Priority 

G 

DeliveryFlags 

M 

otherRecipients 

H 

thisRecipient 

M 

i  nt endedRec  ipi  ent 

H 

converted 

X 

submission 

M 
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Table  1 1  -  P2  BodyParts  (concluded) 


Elements  Class  Restrictions  and  Comments 


SFD 

SFD . Document  M 
TIFl 

T73  Document  M 

T73 .ProtocolElement  H  See  note. 


Note:     This  element  is  not  an  addition  to  the  definition  of  the  BodyPart. 
It  is  described  here  to  show  that  the  SEQUENCE  may  contain  zero 
elements.  A  Problem  Report  has  been  submitted  to  the  CCITT  to 
clarify  whether  this  is  permissible.  The  NIST/OSI  Workshop 
will  adopt  the  CCITT  decision. 


5.4      Reliable  Transfer  Server  (RTS) 


5.4.1        Implementation  Strategy 

Based  on  X.410  Clause  3  and  X.411  Clause  3.5. 


5.4.2       RTS  Option  Selection 

The  maximum  number  of  simultaneous  associations  is  not  limited  in  this  profile;  if  the  capacity  of  a 
system  is  exceeded,  it  should  not  initiate  or  accept  additional  associations. 

Associations  are  established  by  the  MTA  which  has  messages  to  transfer. 

Associations  are  released  when  they  are  not  needed.  Associations  may  also  be  ended  prematurely  due 
to  Internal  problems  of  the  RTS. 

For  both  monologue  and  two  way  alternate  associations,  the  initiator  keeps  the  initial  turn. 

When  establishing  an  RTS  association,  the  following  rules  apply  to  the  use  of  parameters  in  addition  to 
those  in  X.410  Clause  3.2.1: 

a)  Dialogue  mode:  Monologue  must  be  supported  for  this  profile;  two-way  alternate  Is  used  only 
if  both  partners  agree. 

b)  Initial  turn:  Kept  by  the  initiator  of  the  association. 

The  'priority-mechanism'  and  the  'transfer-time  limit'  are  regarded  as  local  matters. 
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5.4.3       RTS  Protocol  Options  and  Clarifications 

Realization  of  tlie  RTS  protocol  is  subject  to  the  following  rules  in  addition  to  those  specified  in  X.410 
Clause  4: 

a)  One  RTS  association  corresponds  to  one  or  more  consecutive  session  connections  (not 
concurrent  ones).  The  first  is  opened  with  ConnectionData  of  type  OPEN,  and  subsequent  ones 
are  opened  with  type  RECOVER. 

b)  Recovery  of  a  Session  connection  is  only  by  RTS  initiator. 

c)  Checkpoint  size: 

1 )  Checkpointing  and  No  Checkpointing  should  be  supported.  Whenever  possible, 
checkpointing  should  be  used. 

2)  The  minimum  checkpointSize  is  1  (that  is,  1024  octets). 

d)  Window  size: 

1)  Minimal  value  of  1  (if  checkpointing  is  supported). 

2)  WindowSize  =  1  means:  After  an  S-SYNCH-MINOR  request  is  sent,  wait  until  the 
confirmation  is  received  before  issuing  an  S-DATA,  S-SYNCH-MINOR,  or 
S-ACTIVITY-END  request. 

e)  APDUs  should  not  be  blocked  into  one  activity. 

f)  Only  one  SSDU  shall  be  transferred: 

1)  Between  two  adjacent  minor  synch  points. 

2)  Between  minor  synch  points  and  adjacent  S-ACTIVITY-START  and  S-ACTIVITY-END 
requests. 

3)  Between  S-ACTIVITY-START  and  S-ACTIVITY-END  without  checkpoints. 

g)  A  monologue  association  is  defined  as  follows: 

1 )  The  RTS  user  responsible  for  establishing  the  association  is  called  the  initiator. 

2)  The  initiator  keeps  the  initial  turn. 

3)  APDUs  are  transferred  in  the  direction  of  the  initiator  to  the  recipient  only. 

4)  There  shall  be  no  token  passing. 

5)  Only  the  initiator  can  effect  an  orderly  release  of  the  association. 
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b)  A  two-way  alternate  association  is  as  described  in  X.410. 

i)  In  the  UserData  parameter  of  the  S-U-ABORT,  the  ReflectedParameter  will  not  be  used  in  the 
Abort! nfornnation  elenrient. 

I 

j)  When  the  S-ACTIVITY-RESUME  is  used  to  resume  an  activity  in  the  same  session  connection 
as  the  one  in  which  it  started,  this  must  happen  immediately  after  the  activity  has  been 
interrupted  (i.e.,  no  intervening  activity  can  occur).  Otherwise,  X.410  Clause  4.3  paragraph  1  may 
be  violated. 

k)  When  S-ACTIVITY-RESUME  is  used  to  resume  an  activity  started  in  another  session 
connection,  the  following  conditions  must  be  met: 

1)  The  current  session  connection  is  of  type  "recover." 

2)  The  value  of  OldSessionConnectionldentifier  in  S-ACTIVITY-RESUME  must  match  the 
value  of  the  SessionConnectionldentifier  parameter  used  in  the  S-CONNECT  of  the  prior 
session  connection.  This  value  is  also  identical  to  the  SessionConnectionldentifier  in  the 
ConnectionData  (in  PConnect,  in  SS-UserData)  for  the  current  session  connection. 

3)  This  must  occur  as  the  first  activity  of  the  next  session  connection  for  the  same 
RTS-association.  It  must  be  the  first,  othenwise  X.410  Clause  4.5.1  point  1  is  violated. 

NOTE  -  It  Is  In  the  same  RTS-ASSOCIATION  because  the  use  of  S-ACTIVITY-RESUME  only  makes  sense 
within  the  scope  of  one  RTS  association. 

I)  If  the  transfer  of  an  APDU  is  interrupted  before  the  confirmation  of  the  first  checkpoint,  the 
value  of  the  SynchronizationPointSerialNumber  in  S-ACTIVITY-RESUME  should  be  zero,  and  the 
S-ACTIVITY-RESUME  must  be  immediately  followed  by  an  S-ACT!VITY-DISCARD. 

m)  In  S-TOKEN-PLEASE,  the  UserData  parameter  shall  contain  an  integer  conforming  to  X.409 
which  conveys  the  priority. 

n)  The  receiving  RTS  can  use  the  value  of  the  Reason  parameter  in  the 
S-U-EXCEPTION-REPORT  to  suggest  to  the  sending  RTS  that  it  should  either  interrupt  or 
discard  the  current  activity.  S-U-Exception  Reports  are  handled  as  stated  in  Version  5  of  the 
Implementors  Guide  pages  12-13,  paragraph  E-33. 

o)  In  the  case  of  S-P-ABORT,  the  current  activity  (if  any)  is  regarded  as  interrupted,  rather  than 
discarded. 

p)  Table  12  illustrates  the  legal  negotiation  possibilities  allowed  by  X.410  Clause  4.2.1  regarding 
checkpoint  size  and  window  size. 

q)  These  agreements  include  the  provisions  of  Version  6  of  the  Implementors  Guide  identical  in 
all  respects  to  Version  5,  except  that  the  following  points  have  been  added  to  clause  3.5: 

1)  for  section  4.4.1  of  X.410;  "If  the  receiving  RTS  receives  an  S-ACTIVITY-DISCARD 
indication  primitive  and  has  already  issued  a  TRANSFER  indication  primitive,  it  aborts 
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the  connection  (S-U-ABORT  request)  with  the  'transfer  completed'  version  code." 

2)  for  section  4.6.2  of  X.410  'The  'transfer  completed  (7)'  abort  reason  is  used  to 
indicate  to  the  sending  RTS  that  the  receiving  RTS  could  not  discard  the  activity 
because  it  has  already  completed  the  transfer  (issued  a  TRANSFER  indication  primitive)." 
Transfer  completed  (7)  is  also  added  to  the  table  of  abort  reasons  in  this  clause. 


Table  12  -  Checkpoint  Window  Size  of  IP 


acceptor  answer 

CS  =  0 
(or  unspecified) 
WS  unspecified 

CS  =  m 
WS  =  j 
(or  unspecified) 

CS  =  n 
WS  =  j 
(or  unspecified) 

initiator 
proposal 

CS  =  0 
(or  unspecified) 

WS  =  i 
(or  unspecified) 

legal 

legal 

legal 

CS  =  k 
WS  =  i 
(or  unspecified) 

legal 

legal 

not  allowed 

Legend 

CS:    means  CheckpointSize 
WS:    means  WindowSize 

i,  j,  k,  m,  and  n:     are  integer  values  with  the  following  relations: 
0  i  m  i  k  <  n     (values  assigned  to  CS) 
0  <  j  5  i            (values  assigned  to  WS) 

For  unspecified  parameters,  the  default  applies.  In  this  case,  the 
numeric  relations  apply,  that  is,  the  default  values  substitutefor 
the  unspecified  integer. 

5.4.4       RTS  Protocol  Limitations 

The  RTS  Protocol  Limitations  for  this  profile  are  listed  in  table  13. 
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Table  13  -  RTS  Protocol  Elements 


Element  Class 

Res  t  r  i  c t  i  on 

PConnect 

M 

Ua  \^Cix  L  Cilia  l.rsL  OjrllLdA 

M 

n 

Value  -  0. 

pUserData 

M 

checkpoints ize 

H 

w 1 nuo wo 1 z  e 

IT 
II 

dialogueMode 

H 

Connect ionData 

M 

Value  =1. 

TT 
11 

Value  =  8883. 

Var 

open 

RTS  user  data 

G 

recover 

Dcoo  JL  (JIlV^OlXIl^w  L  1  C/Il  J.  06111, 1  L  1  e  E 

RTS  use-r  data 

mTAName 

G 

1  Id  A  X  luuiu    J.  cxxM  L>  11    ^  *t    v^iici  1.  av^  O 

graphic  subset  of  IA5  only. 

pas  o  Wvy-L  U 

c 

Maximum  length  64  octets 

graphic  subset  of  IA5  only. 

r* 
VJ 

SessionConnectionldentif ier 

CallingSSUserRef erence 

M 

nax imuin  xciigun  d4  ocue^s  incxuQing 

encoding  =  62  octets  of  T.61. 

CommonRe f e r enc e 

M 

AdditionalRef erencelnformation 

H 

Maximum  length  4  octets  including 

encoding  =  2  octets  of  T.61. 

PAccept 

G 

DataTransf erSyntax 

M 

Value  =  0. 

pUserData 

M 

checkpoints! ze 

H 

windows ize 

H 

Connec t i onDa t a 

M 
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Table  13  -  RTS  Protocol  Elements  (concluded) 


riiemeni 

X.  I.  X  CX*  1  Oil 

PRefuse 

G 

Re£useReason 

M 

SS  User  Data 

G 

See  Note 

(in  S-TOKEN-PLEASE ) 

Abortlnformation 

G 

(in  S-U-ABORT) 

AbortReason 

H 

ref lectedParameter 

X 

Restricted  to  8  bits. 

End  of 

Definitions 

Note  -  Generated  if  supplied  by  the  RTS 
priority  in  the  TURN-PLEASE  primitive, 
SS-User-Data  in  S-TOKEN-PLEASE. 

-user.  The  RTS  use  may  specify  a 
and  if  so,  it  is  carried  as  the 

5.5      Use  of  Session  Services 

The  session  requirements  and  use  of  session  are  covered  in  part  5  of  this  document. 


5.6      Data  Transfer  Syntax 

This  clause  defines  Presentation  Transfer  Syntax  and  notation  rules  applicable  to  these  agreements. 
Implementations  must  conform  EXACTLY  as  specified  in  X.409  with  no  further  restrictions.  Annex  C 
defines  rendition  of  IA5  Text  and  T61  characters. 


6     PRMD  to  ADMD  and  ADMD  to  ADMD 


6.1  Introduction 

This  clause  defines  the  implementation  agreements  that  apply  to  the  interface  between  two  management 
domains  when  at  least  one  is  an  ADMD.  A  message  arriving  at  an  ADMD  has  either  no  recipient  within 
that  domain  or  one  or  more  recipients  within  that  domain.  In  the  former  case,  the  ADMD  serves  as  a 
relay  between  two  or  more  domains  and  the  actions  required  of  that  ADMD  are  independent  of  the 
nature  (PRMD  or  ADMD)  of  the  domains.  In  the  latter  case,  the  ADMD  is  responsible  for  delivering 
messages  to  the  proper  recipient(s)  within  its  jurisdiction,  and  may  also  be  responsible  for  relaying  the 
message. 

Given  the  two  roles  for  an  ADMD,  this  clause  describes  two  distinct  sets  of  functional  requirements  for 
an  ADMD.  The  first  is  the  relaying  requirement  that  is  needed  to  provide  PRMD  and  other  ADMD 
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interworking.  The  second  is  analogous  to  the  PRMD's  support  to  its  customers  through  the  integrated 
UAs.  These  are  distinct  functional  differences.  The  services  provided  to  the  UAs  of  an  ADMD  are 
independent  of  the  requirement  that  an  ADMD  provide  a  function  for  interworking  with  any  type  of 
Management  Domain  (MD).  Figure  5  illustrates  the  two  roles  played  by  an  ADMD. 

This  clause  is  presented  in  the  form  of  deviations  from  the  agreements  applicable  to  PRMD-to-PRMD 
(sec.  5).  Unless  explicitly  noted  in  the  remainder  of  this  clause,  all  of  the  specifications  for  PRMD  to 
PRMD  apply  to  PRMD  to  ADMD  and  ADMD  to  ADMD. 


PRMD  or  ADMD 

IPM  -  UA 

< — 

MTA 

 P2— 

 Pi- 
ca) 


ADMD 


— > 
— > 


IPM  -  UA 


MTA 


PRMD  or  ADMD 

PRMD  or  ADMD 

IPM  -  UA 

 P2  

-> 

IPM  -  UA 

MTA 

MTA 

I 
I 
I 

PI 

I 
I 
I 
I 
I 


 .  > 


ADMD 


MTA 


<  


I 
I 
I 
I 
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I 

I 
I 
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(b) 


Figure  5  -  An  ADMD  May  (b)  or  May  Not  (a)  Serve  as  a  Relay. 

6.2      Additional  ADMD  Functionality 

The  following  defines  the  additional  ADMD  specific  functionality  required  over  and  above  that  specified  in 
the  PRMD  clause. 
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6.2.1        Relay  Responsibilities  of  an  ADMD 

ADMDs  will  relay  all  content  types  (not  just  P2)  unchanged  in  the  absence  of  a  request  for  conversion. 


6.2.2       PI  Protocol  Classification  Changes 

Table  14  describes  the  changes  to  the  PRMD  P1  Protocol  classifications  required  for  a  delivering 
Administration  domain  (with  respect  to  the  original  message;  this  means  the  domain  which  originates  the 
delivery  reports). 


Table  14  -  Pi  Protocol  Classification  Changes  for  a  Delivering  ADMD 


Protocol  Elements 

Class 

Deliveredlnfo 
typeOfUA 

H 

ReportedRecipientlnfo 

Supplementarylnformation 

H          See  Note  1. 

GlobalDomainldentifier 
PrivateDomainldentif ier 

H 

For  relaying  Administration  domains,  the  classifications  are  all  "X" 

For  originating  Administration  domains,  these  are  all  "NOT  APPLICABLE." 

Notes 

1    Domains  providing  access  to  TELEX/TELETEX  recipients,  whether 
directly  or  indirectly  as  a  result  of  bilateral  agreements 
between  domains,  must  ensure  that  this  information,  when 
present,  is  accessible  by  the  recipient  of  the  delivery  report. 

6.2.3       0/R  Names 

0/R  Names  shall  consist  of: 

a)  CountryName, 

b)  AdministrationDomainName. 
as  well  as  one  of  the  following: 

a)  PrivateDomainName, 

b)  Personal  Name, 

c)  OrganizationName, 
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d)  OrganizationalUnit, 

e)  UniqueUAIdentifier, 

f)  X1 21  Address. 

and  permits  the  optional  inclusion  of  a 
a)  DomainDefinedAttributeList. 

NOTE  -  The  destination  PrivateDomainName  or  OrganizationName  must  be  present  if  destined  for  a 
PRMD.  The  ADMD  relaying  the  message  to  that  destination  PRMD  requires  this  element. 

6.2.4       P1  ADMD  Name 

Management  Domains  (MDs)  must  specify  in  tfie  ADMD  name  field  of  the  0/R  Name 
StandardAttributeList  in  P1 ,  the  name  of  the  Administration  domain: 

a)  to  which  the  message  is  being  sent  (in  recipient  names) 

b)  from  which  the  message  originated  (in  the  originator  name). 

6.3  Interworking  with  Integrated  UAs 

If  the  message  originates  at  a  UA  owned  by  an  ADMD,  or  is  delivered  to  such  a  UA,  the  0/R  Name 
follows  the  same  Form  1  Variant  1  constraints  as  the  base  specifications;  except  that  the  ADMD  name  is 
the  name  of  the  ADMD  that  owns  the  UA  and  instead  of  supplying  a  PRMD  Name,  one  (or  more)  of  the 
following  must  be  provided: 

a)  OrganizationName, 

b)  OrganizationalUnit, 

c)  PersonalName. 
and  may  optionally  include  a 

a)  DomainDefinedAttributeList.  . 

6.4  Differences  with  Other  Profiles 
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6.4.1        TTC  Profile 

There  are  no  outstanding  issues  regarding  intenA/orking  between  TTC-conformant  systems  and 
N!ST-conformant  systems  with  the  exception  of  the  number  of  recipients  and  the  supported  MPDU  sizes. 
The  Extensionidentifier  field  may  contain  a  maximum  value  of  32K-1 ;  however,  according  to  the  current 
TTC  profile,  if  a  message  with  more  than  256  recipients  is  received,  some  TTC-conformant  domain  may 
generate  a  nondelivery  notification.  This  also  applies  to  the  ReportedRecipientlnfo  in  a  delivery  report. 
Further,  a  TTC  MTA  is  required  to  handle  an  MPDU  size  of  at  least  32KB.  The  NIST  required  MPDU  size 
is  2MB  as  covered  in  clause  5.3.3.  Other  differences  are  shown  in  annex  E.  TTC  is  currently  based  on 
Version  4  of  the  Implementor's  Guide. 


6.4.2        CEPT  Profile 

See  annex  E. 


6.5      Connection  of  PRMDs  to  Multiple  ADMDs 

Given  that  Management  Domain  names  (both  PRMD  and  ADMD)  shall  be  unique  within  the  United 
States,  then  when  an  ADMD  is  presented  a  message  for  transfer  from  a  PRMD,  it  will  accept  0/R  Names 
(both  originator  and  recipient)  which  have  an  AdministrationDomainName  field  value  different  than  the 
Administration's  name.  "Accept"  implies  the  attempt  to  route/deliver  the  message  shall  be  made,  as 
appropriate,  based  upon  the  knowledge  that  MD  names  are  unique. 

Whether  this  functionality  is  required  by  an  Administration  for  conformance  to  this  agreement  is  for 
further  study. 

If  a  PRMD  is  connected  to  two  or  more  ADMDs  which  are  not  effectively  connected  (either  directly  or  via 
a  third  ADMD),  full  X.400  functionality  shall  not  be  available.  Problems  occur  especially  in  the  areas  of: 

a)  Naming, 

b)  Routing, 

c)  Replying. 

It  should  be  noted  that  a  single  PRMD  that  is  connected  to  more  than  one  ADMD  can  be  represented  by 
more  than  one  combination  of  country-name,  ADMD-name,  and  PRMD  name.  For  example,  it  may  occur 
that  the  PRMD-name  for  a  particular  PRMD  may  take  different  values,  depending  on  the  ADMD-name. 
Implementors  should  be  aware  of  the  consequences  of  these  possibilities  on  routing. 


6.6      Connection  of  an  ADMD  to  a  Routing  PRMD 

It  is  possible  for  a  collection  of  interconnected  private  domains  to  establish  one  domain  as  the  "gateway" 
to  an  ADMD,  and  hence  to  the  world. 
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!f  an  ADMD  is  connected  to  such  a  gateway  PRMD,  the  individual  private  domains  shall  be  registered 
with  the  Administration.  Administrations  need  not  support  such  connections. 

Note  also  that  upon  receipt  by  the  ADMD  of  a  message  originating  somewhere  within  the  PRMD 
collection,  that  the  Tracelnformation  may  contain  more  than  one  element. 

The  X.400  Recommendations  specify  that  an  ADMD  should  not  attempt  to  relay  a  message  destined  for 
another  ADMD  through  a  PRMD,  thus  an  ADMD  should  ensure  that  messages  destined  for  another 
ADMD  are  not  relayed  through  a  PRMD.  It  should  be  noted,  however,  that  a  relaying  PRMD  will  relay  any 
such  message  it  receives. 

6.7  IVIanagament  Domain  Names 

All  Management  Domain  Names  (both  Private  and  Administration)  shall  be  unique  within  the  U.S. 
A  central  naming  authority  shall  be  established  to  register  domain  names. 

6.8  Envelope  VaHdatiori  Errors 

For  validation  errors,  a  non-delivery  notice  shall  be  generated  (if  possible)  with  reason  code  of 
'unableToTransfer'  and  diagnostic  code  of  'invalid Parameters'  (unless  specified  othen/*/ise). 

ADMDs  will  validate  P1  Envelopes  in  the  following  areas: 

a)  The  X.409  syntax  of  all  elements  should  be  checked. 

b)  The  pragmatic  constraint  limits  (lengths  of  fields  and  number  of  occurrences  of  fields)  should 
be  checked. 

c)  Semantic  validation  of  the  following  elements  should  be  done: 

1)  originator  0/R  Name, 

2)  recipient  0/R  Name  in  the  Recipientlnfo, 

3)  Priority. 

d)  Only  recipient  Names  with  the  responsibility  flag  set  should  be  validated.  The  validation  of 
0/R  names  is  defined  in  8.3.3;  the  validation  of  priority  is  defined  in  8.3.7.1. 

e)  MPDU  Identifier  Validation 

1)  Validation  of  the  GlobalDomainldentifier  component  of  the  MPDU  Identifier  is 
performed  upon  reception  of  a  message  (i.e.,  as  a  result  of  a  TRANSFER.Indication). 

2)  The  country  name  should  be  known  to  the  validating  domain,  and  depending  on  the 

country  name,  validation  of  the  ADMD  name  may  also  be  possible. 
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3)  Additional  validation  of  tlie  GiobalDomainldentifier  is  performed  against  the 
corresponding  first  entry  in  the  Tracelnfornriation.  If  inconsistencies  are  found  during  the 
comparison,  a  non-delivery  notice  with  the  above  defined  reason  and  diagnostic  codes 
is  generated. 

4)  A  request  will  be  generated  to  the  CCITT  for  a  more  meaningful  diagnostic  code 
(such  as  'InconsistentMPDUIdentifier'). 


6.9      Quality  of  Service 


6.9.1        Domain  Availability 


6.9.1.1         ADMD  Availability 

The  goal  is  to  provide  24  hour  per  day  availability.  Note  that  there  will  be  periods  of  time  when  an  ADMD 
may  be  unavailable  due  lo  maintenance  windows  in  its  supporting  network  or  in  an  MTA  within  the 
domain. 


6.9.1.2        PRMD  Availability 

Although  the  goal  of  PRMD  availability  is  also  24  hours  per  day,  business  reasons  are  likely  to  dictate 
some  different  level  of  availability.  ADMDs  shall  require  a  profile  from  the  PRMD  that  indicates  its 
schedule  of  regular  availability  to  the  ADMD. 


6.9.2       Delivery  Times 

In  the  absence  of  standardized  quality  of  service  parameters,  the  following  are  agreed  to.  When 
standardized  parameters  from  CCITT  Study  Group  I  become  available,  they  shall  be  adopted. 

a)  In  table  15  the  delivery  time  targets  are  established. 

b)  The  interval(s)  between  retries  and  the  number  of  retry  attempts  that  an  ADMD  uses  in 
attempting  delivery  to  a  PRMD  or  integrated  UA,  will  be  locally  determined  domain  parameters. 
However,  the  total  elapsed  times  after  which  delivery  attempts  will  be  stopped  are  shown  in  table 
16.  This  implies  that,  after  these  times,  a  Non-Delivery  Notice  will  be  generated. 

c)  An  Administration  shall  continue  to  attempt  delivery  until  the  forced  nondelivery  time,  even  if 
the  recipient  domain  has  scheduled  an  unavailability  window. 
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Table  15  -  Delivery  Time  Targets 


Delivery  Class 

95%  Delivered  Before 

Urgent 
Normal 
Non-Urgent 

3/4  hour 
4  hours 
24  hours 

Table  16  -  Forced  Nondelivery  Times 


Delivery  Class 

NonDelivery  Forced  After 

Urgent 
Normal 
Non-Urgent 

4  hours 
24  hours 
36  hours 

NOTE  -  Both  tables  apply  to  the  period  between  acceptance  by  the  originating  MTA  in  the  originating 
Administration  domain  to  the  time  of  delivery  in  the  destination  Administration  domain.  Transit  time  within 
PRMDs  is  NOT  included  in  the  above  times. 

6.10  Billing  Information 

All  aspects  relating  to  billing,  charging,  tariffs,  settlement,  and  in  particular  to  the  use  of  the 
billinglnformation  field  in  the  delivery  report,  is  subject  to  bilateral  agreement,  and  shall  not  be  addressed 
in  these  implementation  agreements. 

No  ADMD  shall  require  a  PRMD  to  supply  or  process  billing  information. 

6.11  Transparency 

No  P1  extensions,  other  than  the  MOTIS  extensions  are  to  be  allowed  (Reference  A/3211).  Should  an 
ADMD  receive  a  message  containing  PI  extensions,  it  shall  generate  a  non-delivery  notice  (if  possible) 
with  reason  code  of  unableToTransfer  and  diagnostic  cede  of  invalid  Parameters. 

If  MOTIS  elements  are  present,  a  relaying  MTA  can  optionally: 

a)  Relay  the  message.  If  the  MTA  does  relay,  it  must  not  drop  any  of  the  protocol  elements. 

b)  Non-Del  iver  the  message. 
A  receiving  MTA  can  optionally: 

a)  Deliver  the  message 

b)  Non-Deliver  the  message. 

The  CCITT  has  been  requested  to  establish  a  more  meaningful  diagnostic  code  (such  as  protocol  Error) 
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for  this  occurrence.  Such  a  code  has  now  been  provided  in  the  Implementors  Guide. 
P2  extensions  shall  be  relayed  transparently  by  ADMDs. 


6.12    RTS  Password  Management 

RTS  password  management  shall  be  a  local  matter.  This  includes: 

a)  password  length 

b)  frequency  of  changes 

c)  exchange  of  passwords  with  communicating  partners 

d)  loading  passwords  (i.e.,  the  timing  of  password  changes  with  respect  to  active 
associations). 


6.13    For  Further  Study 

Issues  requiring  further  study  are: 

a)  Intra-Domain  Routing 

b)  Multi-Vendor  Domains 


7    Inter  and  Intra  PRMD  Connections 


7.1  Introduction 

This  clause  is  limited  in  scope  to  issues  arising  from  the  indirect  connection  of  a  PRMD  to  another 
PRMD  or  to  an  ADMD,  and  to  the  interconnection  of  MTAs  to  form  inter-PRMD  connections.  Indirect 
means  that  the  connection  is  made  via  a  relaying  PRMD.  The  X.400  Recommendations  describe  the  way 
that  a  PRMD  connects  to  a  ADMD  and  the  way  that  an  ADMD  connects  to  another  ADMD.  The 
Recommendations  do  not,  however,  describe  the  way  that  a  PRMD  connects  indirectly  to  an  ADMD  or 
another  PRMD,  nor  do  they  describe  the  way  that  MTAs  are  connected  within  a  PRMD.  These 
configurations  (shown  in  figures  6  and  7)  are  useful,  for  example,  in  connecting  equipment  from  different 
vendors  at  a  single  customer  site. 

The  P1  protocol  and  its  related  services  for  both  inter  and  intra  PRMD  connections  are  addressed  in  this 
clause.  In  addition,  a  method  for  routing  within  a  PRMD  is  given.  It  is  recognized  that  uniform  methods 
for  Administration,  maintenance,  and  quality  of  service  should  be  developed  for  such  configurations,  and 
this  work  is  for  further  study. 

This  clause  describes  the  minimum  that  must  be  provided  in  order  to  implement  a  relaying  PRMD  and  a 
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MTA  within  a  PRMD. 

This  clause  is  presented  in  the  form  of  deviations  from  agreements  applicable  to  PRMD  to  PRMD 
connection  (sec.  5).  That  is,  unless  specifically  noted  in  the  remainder  of  this  clause,  the  agreements  in 
clause  5  apply  to  both  relaying  PRMDs  and  MTAs  within  a  PRMD. 

It  should  be  noted  that  the  comments  regarding  ORNames  in  clause  6.5  also  apply  to  this  clause. 


7.2      The  Relaying  PRMD 

A  PRMD  that  has  the  capability  of  relaying  messages  to  another  PRMD  is  ceiled  a  relaying  PRMD.  A 
PRMD  implementation  need  not  claim  to  be  a  relaying  PRMD.  A  PRMD  implementation  which  does  claim 
to  be  a  relaying  PRMD  must  follow  the  implementation  agreements  in  this  clause. 


7.2.1       Relay  ResponsibilitEes  of  a  PRMD 

The  responsibilities  of  a  relaying  PRMD  are  the  same  as  those  of  an  ADMD  (as  specified  in  sees.  6.8  and 
6.2.1).  In  addition,  the  PRMD  will  simply  deliver  messages  routed  to  it  from  an  ADMD,  even  if  this  results 
in  routing  a  message  from  the  ADMD  to  the  PRMD  to  another  ADMD. 


7.2.2       Interaction  with  an  ADMD 

In  order  for  an  ADMD  to  route  a  message  to  ADMD  A  via  ADMD  B,  it  must  know  that  A  is  reachable 
through  B.  Similarly,  in  order  for  any  MD  to  route  a  message  to  PRMD  A  via  a  relaying  PRMD  B,  it  must 
know  that  A  is  reachable  through  B  (see  figure  8). 


ADMD 


1   PRMD  A 

PRMD  B 

PRMD  C 

Relay 


Figure  6  -  Relaying  PRMD. 
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PRMD 


MTA  A 


MTA  D 


MTA  B 


MTA  C 


ADMD 

or 
PRMD 


Figure  7  -  Intra  PRMD  connections. 


NOTES 


1  Clause  6.6  specifies  that  ADMDs  are  not  required  to  connect  to  a  relaying  PRMD,  but  they  are  not 
precluded  from  doing  so. 

2  Tracelnformation  may  have  more  than  one  sequence  on  submission  of  a  message  by  a  relaying  PRMD 
to  an  ADMD. 


MD  D 


relay 

MD    C  with 
a  message 
for  A 


relay 
MD  B 

MD  A 

Figure  8  -  MD  C  must  know  of  A  to  route  the  message. 


7.3      Intra  PRMD  Connections 

A  PRMD  is  composed  of  MTAs  which  cooperate  to  perform  the  functions  expected  of  a  domain.  An  MTA 
li   implementation  need  not  claim  to  follow  the  implementation  agreements  of  this  clause. 


7.3.1       Relay  Responsibilities  of  an  MTA 

The  relaying  responsibilities  of  an  MTA  are  the  same  as  those  of  an  ADMD  (as  specified  in  6.8  and  6.2.1) 
with  one  exception:  loop  suppression  within  the  domain  is  done  using  the  MOTIS  InternalTracelnfo 
protocol  element.  The  MTA  must  validate  the  InternalTracelnfo  (see  8.3.5  for  details  on  validation).  In 
addition,  the  PRMD  will  simply  deliver  messages  routed  to  it  from  an  ADMD,  even  if  this  results  in  routing 
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a  message  from  the  ADMD  to  the  PRMD  to  another  ADMD  (please  see  6.6). 


7.3.2       Loop  Suppression  within  a  PRMD 

The  only  mechanism  defined  In  the  X.400  Recommendations  for  suppressing  loops  Is  Tracelnformatlon, 
which  Is  added  on  a  per  domain  basis  to  detect  and  suppress  loops  among  domains.  Loops  among 
MTAs  within  a  domain  need  to  be  detected  and  suppressed.  This  implies  that  each  MTA  must  add  trace 
information  that  is  meaningful  within  the  domain.  The  MOTIS  solution  of  adding  InternalTracelnfo  to  the 
PI  Envelope  of  a  message  was  adopted.  The  definition  of  InternalTracelnfo  Is  given  in  figure  9.  The 
InternalTracelnfo  Is  added  by  each  MTA  within  a  PRMD  to  handle  a  message,  and  It  Is  examined  In  the 
same  way  as  Tracelnformatlon  to  detect  and  suppress  loops. 


InternalTracelnfo 

:;=  [APPLICATION  30]   IMPLICIT  SEQUENCE  OF  SEQUENCE  { 

MTAName , 

MTASuppliedlnfo  } 

MTAName 

::=  PrintableString 

Figure  9  -  Definition  of  InternalTracelnfo. 


If  the  MTAName  and  password  of  X.41 1  are  used  for  validation,  then  it  Is  recommended  that  the 
MTAName  used  for  validation  also  be  used  In  the  InternalTracelnfo.  However,  there  Is  a  complication:  In 
X.41 1 ,  MTAName  Is  an  lASStrlng,  and  the  MTAname  defined  by  MOTIS  Is  a  PrintableString.  Efforts  will  be 
made  to  change  the  MOTIS  definition  from  PrintableString  to  lASString. 

Three  actions  are  defined  in  MTASuppliedlnfo:  relayed,  rerouted,  and  reclplentReasslgnment  as  shown  in 
figure  10.  The  reclplentReasslgnment  action  Is  not  supported  In  these  agreements.  The  ability  to 
generate  It  Is  not  required,  and  if  It  Is  present  on  an  Incoming  message,  the  action  field  will  be  ignored. 


MTASuppliedlnfo 

;:=  SET  { 

arrival 

[0]  IMPLICIT  Time, 

deferred 

[1]   IMPLICIT  Time  OPTIONAL, 

action 

[2]   IMPLICIT  INTEGER  { 

relayed 

(0), 

rerouted 

(1). 

recipientReassignment 

(2)  } 

previous 

MTAName  OPTIONAL  } 

Figure  10  -  Defined  Actions  in  MTASuppliedlnfo. 


7.3.3        Routing  Within  a  PRMD 

Routing  within  a  PRMD  Is  complicated  by  the  lack  of  a  directory  standard.  In  particular,  it  constrains 
intra-domain  routing  decisions  to  be  based  on  some  combination  of  the  Intra-domain  attributes  of  the 
0/R  Name,  Organization  Name  Organizational  Units,  and  Personal  Name.  In  order  to  enhance 
interworking  and  to  reduce  the  difficulty  of  configuring  intra-domain  connections.  It  Is  useful  to  restrict 
the  ways  in  which  these  may  be  used  In  making  routing  decisions. 
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However,  it  is  recognized  that  vendors  may  wish  to  provide  MTAs  with  varying  degrees  of  routing 
cafDability  within  a  PRMD  as  a  temporary  expedient  until  appropriate  standards  for  automated 
construction  of  directories  and  routing  tables  are  available.  This  clause  assigns  class  numbers  to  certain 
levels  of  routing  capability  and  discusses  the  consequences  of  using  MTAs  which  fall  into  each  class. 
The  classification  scheme  will  allow  some  diversity  in  allocating  0/R  Name  space  and  in  configuring 
intra-domain  routes. 

When  other  methods  are  recommerwJed  by  standards  bodies,  the  classification  scheme  described  here 
will  become  obsolete.  Large-scale,  multi-vendor  PRMDs  may  not  be  practical  in  the  absence  of 
standardized  methods. 


7.3.3.1         Class  Designations 

When  it  is  clear  that  a  message  is  to  be  delivered  within  a  domain,  the  Country  Name,  ADMD  Name,  and 
PRMD  Name  have  already  served  their  purpose  in  determining  the  next  MTA  in  the  route  to  the  recipient. 
The  remaining  fields  that  might  be  used  on  mai<ing  routing  decisions  within  the  PRMD  are  the 
Organization  Name,  Organizational  Units,  and  Personal  Name. 

MTAs  are  classified  by  their  ability  to  discriminate  between  0/R  names  when  making  routing  decisions 
within  a  PRMD.  Conformant  MTAs  will  be  classified  as  shown  in  table  17. 


Tabie  17  •-  Conformant  MTA  Classifications 


Class  1 

Class  2 

Class  3 

Organization  Name 

H 

H 

H 

SEQUENCE  OF  Organizational  Unit 

X 

H 

H 

Personal  Name 

X 

X 

H 

An  'H'  means  that  the  MTA  must  be  able  to  base  its  intra-domain  routing  decisions  on  the  given 
component  of  the  0/R  Name.  In  particular,  both  Class  2  and  Class  3  MTAs  must  be  able  to  discriminate 
on  all  the  members  in  a  supplied  sequence  of  OrganizationalUnits.  A  Class  3  MTA  must  be  able  to 
discriminate  on  all  of  the  elements  in  a  PersonalName. 

An  'X'  means  that  the  MTA  need  not  have  the  ability  to  discriminate  on  the  given  component. 

There  is  a  hierarchy  in  support  of  components.  The  ability  to  discriminate  on  a  given  component  does 
not  imply  the  requirement  to  do  so:  e.g.,  a  Class  3  MTA  is  not  required  to  have  tables  for  every 
PersonalName  in  the  domain.  Equally,  an  MTA  which  can  discriminate  on  OrganizationalUnits  to  make 
routing  decisions  need  not  always  use  the  full  sequence  in  an  0/R  Name  if  a  partial  sequence  provides 
enough  information. 

The  above  classifications  only  apply  to  routing  decisions  in  selecting  a  next  hop  within  a  domain.  All 
MTAs  are  entitled  to  examine  the  full  0/R  Name  when  identifying  their  own  directly  served  UAs. 

The  routing  table  of  a  Class  1  MTA  will  be  relatively  small,  because  intra-domain  routing  decisions  are 
based  solely  on  OrganizationName.  The  routing  table  of  a  Class  2  MTA  may  be  substantially  larger  and 
more  complex  because  of  its  ability  to  discriminate  on  OrganizationalUnits  as  well  as  OrganizationName 
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to  make  routing  decisions.  The  routing  table  of  a  Class  3  MTA  may  be  larger  still,  because  its  use  of  the 
components  of  PersonalName  in  addition  to  the  other  information. 


7.3.3.2        Specification  of  MTA  Classes 

If  an  MTA  implementation  claims  to  follow  the  implementation  agreements,  it  must  be  either  a  Class  1, 
Class  2,  or  a  Class  3  MTA.  The  class  of  an  MTA  implementation  should  be  specified  so  that  PRMD 
administrators  can  choose  equipment  properly. 


7.3.3.3        Consequences  of  Using  Certain  Classes  of  MTAs 

Definition:  An  MTA  which  accepts  submission  requests  and  furnishes  delivery  Indications  to  a  UA  is  said 
to  "directly  serve"  the  UA. 

The  presence  in  a  domain  of  an  MTA  acting  as  a  Class  1  or  Class  2  MTA  imposes  administrative 
restrictions  on  the  assignment  of  0/R  Names  to  UAs  and  in  the  configuration  of  routes  within  that 
domain. 

A  Class  1  MTA  may  directly  serve  UAs  from  several  OrganizationNames.  However,  If  a  Class  1  MTA 
directly  serves  a  UA  with  a  given  OrganizationName,  no  other  MTA  in  the  domain  may  directly  serve  a 
user  with  the  same  OrganizationName.  This  means  that  if  all  MTAs  in  a  domain  are  Class  1 ,  then  all  UAs 
with  a  given  OrganizationName  must  be  assigned  to  the  same  MTA. 

A  Class  2  MTA  may  directly  serve  UAs  from  any  combination  of  OrganizationName  and  sequence  of 
OrganizationalUnits.  However,  if  a  Class  2  MTA  directly  serves  a  UA  with  a  given  combination,  no  other 
MTA  in  the  domain  may  directly  serve  a  user  with  the  same  combination.  This  means  that  if  all  MTAs  in  a 
domain  are  Class  2,  then  all  UAs  with  a  given  OrganizationName  and  sequence  of  OrganizationalUnits 
must  be  assigned  to  the  same  MTA. 

A  domain  consisting  entirely  of  Class  3  MTAs  is  free  of  all  the  above  restrictions. 

If  Class  1  or  Class  2  MTAs  are  used  to  perform  relaying  within  a  PRMD  containing  MTAs  of  other 
classes,  care  must  be  exercised  in  determining  the  topology  of  the  domain  to  avoid  leaving  certain  UAs 
inacessible  from  certain  MTAs  within  the  domain.  The  example  below  shows  one  of  the  configurations 
that  should  be  avoided.  The  example  is  intended  to  stimulate  careful  examination  of  the  relationship 
between  network  and  organizational  topologies. 


MTA  A 
serving 
Organization  X 


MTA  B 
(Class  1) 


MTA  C 
serving 
Organization  X 


Figure  11  -  Example  of  a  Configuration  to  be  Avoided. 
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In  figure  1 1 ,  B  will  route  all  messages  for  Organization  X  to  either  A  or  C  because  B  is  a  Class  1  MTA. 
The  administrator  who  created  this  configuration  probably  wanted  B  to  route  some  messages  for 
Organization  X  to  A,  and  some  to  C.  However,  B  does  not  have  the  capability  for  this  because  it  is  only 
a  Class  1  MTA.  The  configuration  in  figure  1 1  can  be  corrected  by  replacing  B  with  a  Class  2  or  Class  3 
MTA. 

i 

I  7.3.4       Uniqueness  of  MPDUIdentifiers  Within  a  PRMD 

j  When  generating  an  lASString  in  an  MPDUIdentifier,  each  MTA  in  a  domain  must  ensure  that  the  string  is 
I  unique  within  the  domain.  This  shall  be  done  by  providing  an  MTA  designator  with  a  length  of  1 2  octets 
I  which  is  unique  within  the  domain,  to  be  concatenated  to  a  per  message  string  with  maximum  length  of 
i  20  octets. 

I  Two  pieces  of  information,  the  MTA  name  and  MTA  designator,  need  to  be  registered  within  a  PRMD  to 
guarantee  uniqueness.  This  registration  facility  need  not  be  automated.  If  the  MTA  name  is  less  than  or 
equal  to  1 2  characters,  it  is  recommended  that  it  also  be  used  as  the  MTA  designator. 


7.4      Service  Elements  and  Optional  User  Facilities 

A  PRMD  made  up  of  MTAs  which  support  varying  sets  of  service  elements  in  addition  to  those  required 
in  these  agreements  may  appear  to  provide  inconsistent  service  for  these  elements.  For  example,  if  one 
MTA  supports  deferred  delivery  and  another  MTA  does  not,  then  deferred  delivery  can  be  used  by  some, 
j  but  not  all,  users  in  the  PRMD.  Similarly,  if  one  MTA  supports  return  of  contents  and  another  does  not, 
then  a  user  outside  of  the  PRMD  will  receive  returned  contents  for  messages  sent  to  one  user,  but  not 
for  messages  sent  to  another  user.  Note  that  this  same  inconsistency  occurs  when  sending  to  two 
PRMDs  which  support  different  additional  optional  elements. 


7.5      X.400  Protocol  Definitions 

This  clause  describes  additions  and  modifications  to  clause  5.3  which  are  required  for  implementation  of 
a  relaying  PRMD  or  an  MTA  within  a  PRMD. 


7.5.1       Protocol  Classification 

The  classification  scheme  given  in  clause  5.3.1  applies  to  elements  passing  from  one  PRMD  to  another. 
For  both  relaying  PRMDs,  and  MTAs  in  a  PRMD,  the  same  classification  scheme  will  be  used,  but  within 
a  PRMD  the  classification  applies  to  elements  passing  from  one  MTA  to  another. 

In  addition  to  the  classifications  given  in  clause  5.3.1,  a  classification  of  Prohibited  has  been  used. 
PROHIBITED  =  P 

This  element  shall  not  be  used.  Presence  of  this  element  is  a  protocol  violation. 
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7.5.2       PI  Protocol  Elements 

Table  18  contains  protocol  elements  and  their  classes.  An  *  signifies  that  the  classification  of  the 
protocol  element  has  not  changed  from  table  8. 


Table  18  -  Pi  Protocol  Elements 


Element 

Class 

Restrictions  and  Comments 

UMPDUEnvelope 
MPDUIdentif ier 

M* 

This  field  needs  to  be  unique 
within  a  PRMD.    See  clause 
7,3.4  for  the  method  of 
ensuring  uniqueness. 

originator 

M* 

It  is  recommended  that  all 
components  of  the  originator's 
ORName  be  included  to  help  ensure 
that  reports  can  be  returned. 

Tracelnformation 

M* 

The  first  MTA  in  the  domain  to 
receive  the  message  adds  the 
Tracelnformation.  Subsequent 
MTAs  can  update  the 
Tracelnformation  in  the  event  of 
conversion  or  deferred  delivery. 
When  a  message  is  generated,  the 
originating  MTA  adds  the 
Tracelnformation. 

InternalTracelnfo 

M/P 

This  element  is  mandatory  for 
envelopes  transferred  between 
MTAs  within  a  PRMD,  and 
prohibited  in  messages 
transferred  outside  the  domain. 
Elements  are  always  added  to  the 
end  of  the  sequence.   (See  Note  1) 

InternalTracelnfo 
MTAName 

M 

MTANames  within  a  PRMD  must  be 
unique.  See  clause  7.3.4  for 
the  method  of  assuring  uniqueness 
Maximum  length  =  32  characters. 

MTASuppl i edinf o 

M 
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Table  18  -  Pi  Protocol  Elements  (continued) 


Element 

Class 

Restrictions  and  Comments 

MTASuppliedlnfo 
arrival 
deferred 

M 
X 

This  field  must  be  generated  by 
MTAs  which  perform  deferred 
delivery. 

action 

M 

See  clause  7.3.2  for 
restrictions  on  values  of  this 
field. 

previous 

X 

This  field  must  be  generated  by 
MTAs  which  perform  rerouting. 

De 1 i ve r y Repo r t En ve 1 ope 
TraceIn£orination 

M* 

The  first  MTA  in  the  domain  to 
receive  the  report  adds  the 
Tracelnformation.  When  a  report 
is  generated,  the  originating  MTA 
adds  the  Tracelnformation. 

InternalTracelnfo 

DeliveryReportContent 

intermediate  InternalTracelnfo 

M/P 
P 

This  field  is  mandatory  for 
envelopes  transferred  between 
MTAs  within  a  PRMD,  and 
prohibited  in  messages 
transferred  outside  the  domain. 
(See  Note  1) 

If  it  were  possible  to  include 
this  field  in  the  delivery  report 
content,  an  audit  and  confirmed 
report  could  be  provided  to 
detect  problems  within  a  PRMD. 
Efforts  are  being  made  to  add 
this  field  to  the  MOTIS 
definition. 

Deliveredlnfo 
typeOFUA 

R* 

It  is  the  responsibility  of  the 
MTA  generating  the  report  to 
generate  this  element. 
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Table  18  -  PI  Protocol  Elements  (concluded) 


Element 

Class 

Restrictions  and  Comments 

ProbeEnvelope 

Tracelnformation 

M* 

The  first  MTA  in  the  domain  to 
receive  the  probe  adds  the 
Tracelnformation.  When  a  probe 
is  generated,  the  originating  MTA 
adds  the  Tracelnformation. 

InternalTracelnfo 

M/P 

This  field  is  mandatory  for 
envelopes  transferred  between 
MTAs  within  a  PRMD,  and 
prohibited  in  messages 
transferred  outside  the  domain. 
(See  Note  1) 

Notes 

1    The  M  classification 
claiming  conformance 

is  only  applicable  if  an  implementation  is 
according  to  clause  10.2. 

7.5.3       Reliable  Transfer  Server  (RTS) 

In  the  pUserData  of  PConnect,  the  value  of  appllcationProtocol  should  be  1 .  This  value  was  chosen 
because  the  agreements  on  intra-domain  connections  are  not  strictly  P1 ,  nor  are  they  MOTIS. 
Philosophically,  it  would  be  good  to  choose  a  new  application  protocol  identifier  for  these  agreements, 
but  this  introduces  too  many  practical  problems.  Since  these  agreements  are  closer  to  P1  than  to 
MOTIS,  the  value  of  1  will  be  used.  This  will  not  cause  intenA^orking  problems  between  domains,  because 
the  only  deviation  from  P1  is  the  InternalTracelnfo,  which  will  not  be  present  in  messages  transferred 
outside  of  a  domain. 


8     Error  Handling 

This  clause  describes  appropriate  actions  to  be  taken  upon  receipt  of  protocol  elements  which  are  not 
supported  in  this  profile,  malformed  MPDUs,  unrecognized  0/R  Name  forms,  content  errors,  errors  in 
reports,  and  unexpected  values  for  protocol  elements. 


8.1      MPDU  Encoding 

The  MPDU  should  have  a  context-specific  tag  of  0,  1 ,  or  2.  If  it  does  not  have  one  of  these  tags,  it  is  not 
possible  to  figure  out  who  originated  the  message.  Therefore,  the  way  this  error  is  reported  is  a  local 
matter. 
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8.2  Contents 

Once  delivery  to  the  UA  has  occurred,  it  is  not  possible  to  report  errors  in  P2  information  to  the 
originator.  In  addition,  it  seems  unreasonable  to  insist  that  the  MTA  that  delivers  a  message  ensure  that 
the  P2  content  of  the  message  is  acceptable.  As  a  result,  the  handling  of  content  errors  is  a  local  matter. 


8.3  Envelope 

This  clause  describes  the  handling  of  errors  in  message  envelopes.  Some  of  the  error  conditions 
described  below  may  be  detected  in  a  recipient's  0/R  Name.  This  may  limit  the  reporting  MTA's  ability 
to  generate  a  nondelivery  notification  that  accurately  reflects  the  erroneous  0/R  Name  in  the 
ReportedRecipientlnfo.  This  handling  of  this  situation  is  a  local  matter. 


8.3.1       Pragmatic  Constraint  Violations 

In  all  cases  of  pragmatic  constraint  violation,  a  nondelivery  report  should  be  generated  with  a 
ReasonCode  of  unableToTransfer,  and  a  DiagnosticCode  of  pragmaticConstraintViolation. 


8.3.2       Protocol  Violations 

If  all  required  protocol  elements  are  not  present,  a  nondelivery  report  with  a  ReasonCode  of 
unableToTransfer  and  a  DiagnosticCode  of  protocolViolation  should  be  generated. 

If  a  protocol  element  is  expected  to  be  of  one  type,  but  is  encoded  as  another,  then  a  nondelivery  report 
with  a  ReasonCode  of  unableToTransfer  and  a  DiagnosticCode  of  invalid  Parameters  should  be 
generated. 


8.3.3       0/R  Names 

The  domain  that  has  responsibility  for  delivering  a  message  should  also  have  the  responsibility  to  send 
the  nondelivery  notification  if  the  message  cannot  be  delivered.  Therefore,  each  MTA  should  only 
validate  the  0/R  Names  of  recipients  with  responsibility  flags  set  to  TRUE.  In  addition,  a  nondelivery 
notification  can  only  be  sent  if  the  originator's  0/R  Name  is  valid. 

If  any  element  in  the  0/R  Name  is  unrecognized  or  if  the  CountryName,  AdministrationDomainName, 
and  one  of  PrivateDomainName  and  OrganizationName  (and,  for  ADMDs,  PersonalName  and 
OrganizationalUnit)  are  not  all  present,  then  a  nondelivery  report  should  be  generated  with  a 
ReasonCode  of  unableToTransfer,  and  a  DiagnosticCode  of  unrecognizedORName.  If  the  message  can 
be  delivered  even  though  the  ORName  is  invalid,  delivery  is  a  local  matter.  Note,  however,  that  if  the 
message  is  delivered,  the  invalid  ORName  might  be  propagated  through  the  X.400  system  (e.g.,  by 
forwarding). 

If  the  0/R  Name  has  all  of  the  appropriate  protocol  elements  and  the  message  still  cannot  be  delivered 
to  the  recipient,  the  following  DiagnosticCodes  may  appear  in  the  nondelivery  report; 
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unrecognizedORName.ambiguousORName.and  uaUnavailable. 


8.3.4  Tracelnformation 

Since  non-relaying  domains  need  not  do  loop  suppression,  domains  with  responsibility  for  delivering  the 
message  need  not  be  concerned  about  the  semantics  of  the  Tracelnformation,  that  is,  arrival  time  and 
converted  EncodedlnformationTypes  can  be  provide  to  the  UA  without  inspection  by  the  MTAs  of  the 
domain  as  long  as  the  Tracelnformation  is  properly  encoded  according  to  X.409. 

When  a  message  is  accepted  for  relay,  the  relaying  domain  must  check  that  a  Tracelnformation 
SEQUENCE  has  been  added  by  the  domain  that  last  handled  the  message.  If  the  appropriate 
Tracelnformation  was  not  added,  this  should  be  treated  as  a  protocolViolation  (sec.  8.3.2). 

In  addition,  the  relaying  domain  must  check  that  the  information  was  added  in  the  sequence  defined  by 
the  rules  for  adding  Tracelnformation  in  the  CCITT  X.400  Implementor's  Guide.  If  the  sequence  is 
invalid.then  a  nondelivery  report  should  be  generated  with  a  ReasonCode  of  unableToTransfer  and  a 
diagnosticCode  of  invalid  Parameters. 

NOTE  -  It  would  be  desirable  for  the  CCITT  to  add  a  diagnostic  code  of  invalidTracelnformation  to  allow  a 
more  meaningful  description  of  this  problem.  A  request  for  this  new  diagnostic  code  will  be  submitted. 


8.3.5  InternalTracelnfo 

This  clause  applies  only  to  MTAs  which  follow  the  agreements  of  clause  7. 

When  a  message  is  accepted  for  relay  from  another  MTA  in  the  domain,  the  relaying  MTA  must  check 
that  an  InternalTracelnfo  SEQUENCE  has  been  added  by  the  MTA  that  last  handled  the  message.  If  the 
appropriate  InternalTracelnfo  was  not  added,  this  should  be  treated  as  a  protocolViolation  (sec.  8.3.2). 

In  addition,  the  relaying  MTA  must  check  that  the  information  was  added  in  the  sequence  defined  by  the 
rules  for  adding  Tracelnformation  in  the  CCITT  X.400  Implementor's  Guide.  If  the  sequence  is  invalid, 
then  a  nondelivery  report  should  be  generated  with  a  ReasonCode  of  unableToTransfer  and  a 
diagnosticCode  of  invalid  Parameters. 

NOTE  -  It  would  be  desirable  for  the  CCITT  to  add  a  diagnostic  code  of  invalidTracelnformation  to  allow 
for  a  more  meaningful  description  of  this  problem.  A  request  for  this  new  diagnostic  code  will  be  submitted. 


8.3.6       Unsupported  X.400  Protocol  Elements 

The  protocol  elements  defined  in  X.400  but  unsupported  by  this  profile  are:  the  deferredDelivery  and 
PerDomainBilaterallnfo  parameters  of  the  UMPDUEnvelope,  the  ExplicitConversion  parameter  of 
Recipientlnfo,  and  the  alternateRecipientAllowed  and  contentReturnRequest  bits  of  the  PerMessageFlag. 
Appropriate  actions  are  described  below  for  domains  that  do  not  support  the  protocol  elements. 
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8.3.6.1  deferredDellvery 

The  delivering  domain  shall  do  one  of  the  following: 

a)  deliver  at  once, 

b)  hold  for  deferred  delivery, 

c)  return  a  nondelivery  notification  with  a  ReasonCode  of  unableToTransfer  and  a 
DiagnosticCode  of  noBilateralAgreement. 


8.3.6.2  PerDomainBilaterallnfo 

If  a  delivering  domain  receives  this  element,  the  element  can  be  ignored. 


8.3.6.3  ExplicltConverslon 

If  ExplicitConversion  is  requested  the  message  should  be  delivered  if  possible.  That  is,  if  the  UA  is 
registered  to  accept  the  EncodedlnformationTypes  of  the  message,  then  the  message  should  be 
delivered  even  though  the  requested  conversion  could  not  be  performed  along  the  route.  If  delivery  is 
not  possible,  then  a  nondelivery  report  should  be  generated  with  a  ReasonCode  of 
conversionNotPerformed  with  no  DiagnosticCode. 


8.3.6.4  aiternateRecipientAllowed 

If  a  delivering  domain  receives  this  element  the  element  can  be  ignored. 


8.3.6.5  contentReturnRequest 

If  a  delivering  domain  receives  this  element,  the  element  can  be  ignored. 


8.3.7       Unexpected  Values  for  INTEGER  Protocol  Elements 

There  are  three  INTEGERS  in  the  P1  Envelope.  Appropriate  actions  are  described  below  for  domains 
receiving  unexpected  values  for  Priority,  ExplicitConversion,  and  ContentType. 


8.3.7.1  Priority 

Additional  values  for  Priority  have  been  suggested  by  at  least  one  group  of  implementors  as  upward 
compatible  changes  to  the  X.400  Recommendations.  Therefore,  if  a  PRMD  receives  an  unexpected  value 
for  Priority,  and  this  value  is  greater  than  one  byte  in  length,  a  nondelivery  report  should  be  generated 
with  a  ReasonCode  of  unableToTransfer  and  DiagnosticCode  of  invalidParameters.  If  the  value  is  less 
than  or  equal  to  one  byte,  the  PRMD  can  either  generate  a  nondelivery  report  as  previously  specified  or 


49 


I 


Part  7:  1984  Message  Handling  Systems 


December  1990  (Stable)  | 


interpret  the  Priority  as  normal  and  deliver  or  relay  the  message. 


8.3.7.2 


ExpUcitConversion 


When  an  unexpected  value  is  received  for  ExplicitConversion,  It  should  be  handled  as  in  clause  8.3.6.3. 


If  the  ContentType  is  not  supported  by  the  delivering  MTA,  then  a  nondelivery  report  should  be 

generated  with  a  ReasonCode  of  unableToTransfer,  and  a  DiagnosticCode  of  contentTypeNotSupported.  | 

I 

8.3.8       Additional  Elements  ! 


in  the  absence  of  multilateral  agreements  to  the  contrary,  receipt  of  privately  tagged  elements  and 
protocol  elements  in  addition  to  those  defined  in  X.400  will  result  in  a  nondelivery  report  with  a 
ReasonCode  of  unableToTransfer  and  a  DiagnosticCode  of  invalidParameters. 

The  exceptions  to  this  are  the  MOTIS  elements.  The  treatment  of  MPDU's  containing  these  MOTIS 
extensions  is  described  in  clause  6.11. 


BA  Reports 

There  is  no  mechanism  for  returning  a  delivery  or  status  report  due  to  errors  in  the  report  itself. 
Therefore  the  handling  of  errors  in  reports  is  a  local  matter. 


9     MHS  Use  of  Directory  Services 


9.1      Directory  Service  Elements 

Recommendation  X.400  recognizes  the  need  of  MHS  users  for  a  number  of  directory  service  elements. 
Directory  service  elements  are  intended  to  assist  users  and  their  UAs  in  obtaining  information  to  be  used 
in  submitting  messages  for  delivery  by  the  MTS.  The  MTS  may  also  use  directory  service  elements  to 
obtain  information  to  be  used  in  routing  messages.  Some  functional  requirements  of  directories  have 
been  identified  and  are  listed  below: 

a)  Verify  the  existence  of  an  0/R  name. 

b)  Return  the  0/R  address  that  corresponds  to  the  0/R  name  presented. 

c)  Determine  whether  the  0/R  name  presented  denotes  a  user  or  a  distribution  list. 

d)  Return  a  list  of  the  members  of  a  distribution  list. 


8.3.7.3 


ContentType 
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e)  When  given  a  partial  name,  return  a  list  of  0/R  name  possibilities. 

f)  Allow  users  to  scan  directory  entries. 

g)  Allow  users  to  scan  directory  entries  selectively. 

h)  Return  the  capabilities  of  the  entity  referred  to  by  the  0/R  name. 

i)  Provide  maintenance  functions  to  keep  the  directory  up-to-date. 

In  addition  to  functionality,  a  number  of  operational  aspects  must  be  considered.  These  include 
user-friendliness,  flexibility,  availability,  expendability,  and  reliability. 

Currently,  these  aspects  of  directory  service  elements  and  procedures  are  under  study  by  both  the 
CCITT  and  the  ISO.  Both  organizations  are  committed  to  the  development  of  a  single  Directory  Service 
specification  for  use  by  MHS  and  all  other  OS!  based  applications. 

Given  the  incomplete  nature  of  the  ongoing  activities  within  the  CCITT  and  the  ISO,  no  impSementation 
details  will  be  provided  now  for  MHS  use  of  Directory  Services.  Implementation  agreements  for  MHS 
Use  of  Directory  Services  will  be  issued  when  current  activities  within  the  CCITT  and  the  ISO  are  stable. 


9.2      Use  of  Names  and  Addresses 

It  is  recognized  that  these  agreements  enable  a  wide  variety  of  naming  and  addressing  attributes  (see 
sec.  5.3.5  ORName  Protocol  Elements)  wherein  each  PRMD  may  adopt  particular  routing  schemes 
within  its  domain. 

With  the  exception  of  the  intra-domain  connection  agreements: 

a)  These  agreements  make  no  attempt  to  recommend  a  standard  practice  for  electronic  mail 
addressing. 

Inter-PRMD  addressing  may  be  secured  according  to  practices  outside  the  scope  of  these  agreements, 
such  as: 

a)  manual  directories 

b)  on-line  directories 

c)  ORName  address  specifications 

d)  ORName  address  translation. 

Further,  each  PRMD  may  adopt  naming  and  addressing  schemes  wherein  the  user  view  may  take  a  form 
entirely  different  from  the  attributes  reflected  in  table  9.  And,  each  PRMD  may  have  one  user  view  for  the 
originator  form  and  another  for  the  recipient  form,  and  perhaps  other  forms  of  user  addressing.  In  some 
cases  (e.g.,  receipt  notification)  these  user  forms  must  be  preserved  within  the  constraints  of  these 
implementation  agreements.  However,  mapping  between  one  PRMD  user  form  to  another  PRMD  user 
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form,  via  the  X.400  ORName  attributes  of  these  agreements,  is  outside  the  scope  of  these  agreements. 


1 0  Conformance 


10.1  Introduction 

In  order  to  ensure  that  products  conform  to  these  implementation  agreements,  it  is  necessary  to  define 
the  types  and  degrees  of  conformance  testing  that  products  must  pass  before  they  may  be  classified  as 
conformant.  This  clause  defines  the  conformance  requirements  and  provides  guidelines  for  the 
interpretation  of  the  results  from  this  type  of  testing. 

This  clause  is  incomplete  and  will  be  enhanced  in  future  versions  of  this  Agreement.  Later  versions  will 
reflect  the  problems  of  conformance  testing  and  will  outline  specific  practices  and  recommendations  to 
aid  the  development  of  conformance  tests  and  procedures. 


1 0.2    Definition  of  Conformance 

For  this  clause,  the  term  conformance  is  defined  by  the  following: 

a)  The  tests  indicated  for  this  clause  are  intended  to  establish  a  high  degree  of  confidence  in  a 
statement  that  the  implementation  under  test  (lUT)  conforms  (or  does  not  conform)  to  the 
agreements  of  this  clause. 

b)  Conformance  to  a  service  element  means  that  the  information  associated  with  the  service 
element  is  made  accessible  to  the  user  (person  or  process)  whenever  this  agreement  says  that 
this  information  should  be  available.  Accessible  means  that  information  must  be  provided 
describing  how  a  user  (person  or  process): 

1)  causes  appropriate  information  to  be  displayed,  or 

2)  causes  appropriate  information  to  be  obtained. 

c)  Conformance  to  P1 ,  P2,  and  RTS  as  part  of  an  X.400  OSI  application  requires  that  only  the 
external  behavior  of  that  OS!  system  adheres  to  the  relevant  protocol  standards.  In  order  to 
achieve  conformance  to  this  clause,  it  is  not  required  that  the  inter-layer  interfaces  be  available 
for  testing  purposes. 

d)  Conformance  to  the  protocols  requires: 

1)  that  MPDUs  correspond  to  instances  of  syntactically  correct  data  units, 

2)  MPDUs  in  which  the  data  present  in  the  fields  and  the  presence  (or  absence)  of 
those  fields  is  valid  in  type  and  semantics  as  defined  in  X.400,  as  qualified  by  this  profile, 

3)  correct  sequences  of  protocol  data  units  in  responses  (resulting  from  protocol 
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e)  Statements  regarding  the  conformance  of  any  one  implementation  to  this  profile  are  not 
complete  unless  a  Protocol  Implementation  Conformance  Statement  (PICS)  is  supplied. 

f)  The  term  "Implementation  Under  Test"  (lUT)  Is  interchangeable  with  the  term  "system"  in  the 
definition  of  conformance,  and  may  refer  to: 

1)  a  domain,  which  may  be  one  or  more  MTA's  with  co-located  or  remote  UA's, 

2)  a  single  instance  of  an  MTA  and  co-located  UA  with  X.400  (P1,  P2,  RTS  and  session) 
software, 

3)  a  relaying  product  with  PI,  RTS  and  session  software, 

4)  a  gateway  product. 

g)  Claiming  Implementation  Conformance 

1)  An  implementation  which  claims  to  be  conformant  as  an  ADMD  must  adhere  to  the 
agreements  in  clauses  5  and  6. 

2)  An  implementation  which  claims  to  be  conformant  as  a  PRMD  must  adhere  to  the 
agreements  in  clause  5. 

3)  An  implementation  which  claims  to  be  conformant  as  a  relaying  PRMD  must  adhere 
to  the  agreements  in  clause  5  and  the  appropriate  clauses  of  7. 

4)  An  implementation  which  claims  to  be  conformant  to  the  intra-domain  connection 
agreements  must  adhere  to  the  agreements  in  clause  5  and  the  appropriate  clauses  of 
7. 


10.3    Conformance  Requirements 


10.3.1  Introduction 

Conformance  to  this  specification  requires  that  all  the  services  listed  as  supported  in  clauses  5,  6,  and  if 
appropriate,  7  of  these  agreements  are  supported  in  the  manner  defined,  in  either  the  CCITT  X.400 
Recommendations  or  these  agreements.  It  is  not  necessary  to  implement  the  recommended  practices  of 
annex  B,  in  order  to  conform  to  these  agreements. 

It  is  the  intention  to  adopt,  where  and  when  appropriate  the  testing  methodology  and/or  the  abstract 
test  scenarios  currently  being  defined  by  the  CCITT  X.400  Conformance  Group.  However,  it  is 
recognized  that  formal  CCITT  Recommendations  relating  to  X.400  Conformance  Testing  will  not  be 
available  until  1 988.  It  is  also  recognized  that  aspects  of  these  agreements  are  outside  the  scope  of  the 
CCITT,  and  that  other  organizations  will  have  to  provide  conformance  tests  in  these  cases. 
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10.3.2      Initial  Conformance 

This  clause  is  intended  to  provide  guidelines  to  vendors  who  envisage  having  X.400  products  available 
prior  to  any  formal  mechanism,  or  "Conformance  Test  Center"  being  made  accessible  that  would  allow 
for  conformance  to  this  product  specification  to  be  tested. 

It  is  feasible  that  vendors  and  carriers  will  want  to  enter  bilateral  test  agreements  that  will  allow  for  initial 
trials  to  be  carried  out  for  the  purposes  of  testing  initial  IntenA^orking  capabilities.  It  is  equally  feasible  that 
for  the  purposes  of  testing  interoperability,  only  a  subset  of  this  specification  will  initially  be  tested. 

NOTE  -  By  claiming  conformance  to  this  subset  of  information  the  vendor  or  carrier  CANNOT  claim 
conformance  to  this  entire  specification. 

There  are  two  aspects  to  the  requirements,  interworking  and  service,  as  described  in  the  following 
clauses. 


10.3.2.1  Interworking 

The  interworking  requirements  for  conformance  implies  that  tests  be  done  to  check  for  the  syntax  and 
semantics  of  protocol  data  elements  for  a  system  as  defined  by  the  classification  scheme  of  clauses 
5.2.1.1  and  7.5.2.  For  a  relay  system,  the  correct  protocol  elements  should  be  relayed  as  appropriate. 
For  a  recipient  system,  a  message  with  correct  protocol  elements  must  not  be  rejected  where 
appropriate. 


10.3.2.2  Service 

For  information  available  to  the  recipients  via  the  IPMessage  Heading  and  Body,  the  following  should  be 
made  accessible: 


a) 

IPMessage  ID  -  only  the  PrintableString  portion  of  the  IPMessageld  needs  to  be  accessible. 

b) 

subject. 

c) 

primaryRecipients, 

d) 

copyRecipients, 

e) 

blindcopyRecipients, 

f) 

authorizingUsers, 

g) 

originator. 

h) 

inReplyTo, 

i) 

replyToUsers, 
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j)  importance, 

k)  sensitivity, 

I)  lASText  Bodypart. 
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Annex  A  (normative) 

Interpretation  of  X.400  Service  Elements 

The  work  on  service  element  definitions  is  limited  to  those  that  are  defined  as  'supported'  in  clause  5  of 
this  specification.  Furthermore  it  is  not  the  intent  of  this  clause  to  define  how  information  should  be 
made  available  or  presented  to  a  MHS  user,  nor  is  it  intended  to  define  how  individual  vendors  should 
design  their  products.  In  addition,  statements  on  conformance  to  a  specific  service  element  and  the 
allocation  of  error  codes  that  are  generated  as  a  result  of  violations  of  the  sen/ice  should  be  defined  in 
the  clauses  on  conformance  and  errors  as  part  of  the  main  product  specification.  The  main  objective  is 
to  provide  clarification,  where  required,  on  the  functions  of  a  service  element,  and  in  particular  what  the 
original  intent  of  the  Recommendations  were. 


A.I      Service  Elements 

The  following  Sen/ice  Elements  defined  in  X.400  have  been  examined  and  require  further  text  to  be 
added  to  their  definitions  to  represent  the  proposed  implementation  of  these  service  elements  by  the 
X.400  SIG. 

The  service  element  clarifications  are  to  be  taken  in  the  context  of  this  profile. 
Service  elements  not  referenced  in  this  clause  are  as  defined  in  X.400. 


A.2  Probe 

A  PRMD  need  not  generate  probes. 

If  a  probe  is  addressed  to  and  received  by  a  PRMD,  the  PRMD  must  respond  with  a  Delivery  Report  as 
appropriate  at  the  time  the  probe  was  processed. 


A.3      Deferred  Delivery 

In  the  absence  of  bilateral  agreements  to  the  contrary.  Deferred  Delivery  and  Deferred  Delivery 
Cancellation  are  local  matters  (i.e.,  confined  to  the  originating  domain)  and  need  not  be  provided. 

The  extension  of  Deferred  Delivery  beyond  the  boundaries  of  the  initiating  domain  is  via  bilateral 
agreement  as  specified  in  section  3.4.2.1  of  X.41 1. 


A.4     Content  Type  Indication 

It  is  required  that  both  an  originating  and  recipient  domain  be  able  to  support  P2  content  type.  The 
ability  for  domains  to  be  able  to  exchange  content  types  other  than  P2  will  depend  on  the  existence  of 
bilateral  or  multi-lateral  agreements. 
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A.5     Original  Encoded  Information  Types  Indication 

It  is  required  that  both  an  originating  and  recipient  domain  be  able  to  support  IA5  text.  Support  for  other 
encoded  information  types,  for  the  purposes  of  message  transfer  between  domains,  will  depend  on  the 
existence  of  bilateral  or  multi-lateral  agreements. 

The  use  of  the  'unspecified'  form  of  encoded  information  type  should  only  be  used  when  the  UMPDU 
content  represents  an  SR-UAPDU  or  contains  an  auto-forwarded  IM-UAPDU. 

The  original  encoded  information  type  of  a  message  is  not  meaningful  unless  a  message  is  converted  en 
route  to  the  recipient.  These  agreements  support  only  IA5  text,  which  should  not  undergo  conversion. 
The  original  encoded  information  types  should  be  made  accessible  to  the  recipient  for  upward 
compatibility  with  the  use  of  non-IA5  text  message  body  parts. 


A.6      Registered  Encoded  Information  Types 

A  UMPDU  with  an  'unspecified'  value  for  Original  Encoded  Information  Type  shall  be  delivered  to  the  UA. 


A.7      Delivery  Notification 

The  UAContentID  may  be  used  by  the  recipient  of  the  delivery  notification  for  correlation  purposes. 


A.8      Disclosure  of  Other  Recipients 

This  service  is  not  made  available  by  originating  MTAE's  to  UAE's,  but  must  be  supported  by  relaying 
and  recipient  MTAE's. 

By  supporting  the  disclosure  of  other  recipients  the  message  recipient  can  be  informed  of  the  0/R 
names  of  the  other  recipient(s)  of  the  message,  as  defined  in  the  P1  envelope,  in  addition  to  the  0/R 
Descriptors  within  the  P2  header. 

These  agreements  do  not  support  initiation  of  disclosure  of  other  recipients,  but  the  information 
associated  with  it  should  be  made  accessible  to  the  recipient  for  upward  compatibility  with  support  for 
the  initiation  of  this  service  element. 


A.9     Typed  Body 

As  defined  in  X.400  with  the  addition  of  the  Private  Body  Types  that  are  to  be  supported.  At  present 
there  is  no  mechanism  provided  within  X.420  that  would  allow  you  to  respond  to  reception  of  an 
unsupported  body  type. 

Action  taken  in  this  situation  is  a  local  matter. 
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A.10    Blind  Copy  Recipient  Indication 

It  should  be  considered  that  the  recipient's  UA  acts  on  behalf  of  the  recipient,  and  therefore  may  choose 
to  disclose  all  BCC  recipients  to  each  other.  Therefore  it  is  the  responsibility  of  the  originating  domain  to 
submit  two  or  more  messages,  depending  on  whether  or  not  each  BCC  should  be  disclosed  to  each 
other  BCC. 


A.1 1    Auto  Forwarded  Indication 

A  UA  may  choose  not  to  forward  a  message  that  was  previously  auto-forwarded.  In  addition  there  is  no 
requirement  for  an  IPM  UA  that  does  not  support  non-receipt  or  receipt  notification  to  respond  with  a 
non-receipt  notification  when  a  message  is  auto-forwarded. 

A.1 2    Primary  and  Copy  Recipients  Indication 

It  is  required  that  at  least  one  primary  recipient  be  specified;  however,  for  a  fonwarded  message  this 
need  not  be  present.  The  recipient  UA  should  be  prepared  to  accept  no  primary  and  copy  recipients  to 
enable  future  interworking  with  Teletex,  Fax,  etc. 


A.1 3    Sensitivity  Indication 

A  message  originator  should  make  no  assumptions  as  to  the  semantic  interpretation  by  the  recipients 
UA  regarding  classifications  of  sensitivity.  For  example,  a  persona!  message  may  be  printed  on  a  shared 
printer. 


A.1 4    Reply  Request  Indication 

In  requesting  this  service  an  originator  may  additionally  supply  a  date  by  which  the  reply  should  be  sent 
and  a  list  of  the  intended  recipients  of  the  reply.  If  no  such  list  is  provided  then  the  initiator  of  the  reply 
sends  the  reply  to  the  originator  of  the  message  and  any  recipients  the  reply  initiator  wishes  to  include. 
The  replytoUsers  and  the  replyBy  date  may  be  specified  without  any  explicit  reply  being  requested.  This 
may  be  interpreted  by  the  recipient  as  an  implicit  reply  request.  Note  that  for  an  auto-forwarded 
message  an  explicit  or  implicit  reply  request  may  not  be  meaningful. 


A.1 5    Body  Part  Encryption 

The  original  encoded  information  type  indication  includes  the  encoded  information  type(s)  of  message 
body  parts  prior  to  encryption  by  the  originating  domain.  The  ability  for  the  recipient  domain  to  decode 
an  encrypted  body  part  is  a  local  matter.  Successful  use  of  this  facility  can  only  be  guaranteed  if  there 
exists  bilateral  agreements  to  support  the  exchange  of  encrypted  body  parts. 
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A.16    Forwarded  IP  Message  indication 

The  following  use  of  the  original  encoded  information  type  in  the  context  of  fonA^arded  messages  is 
clarified: 

a)  If  forwarding  a  private  message  body  part  the  originator  of  the  forwarded  message  shall  set 
the  original  encoded  information  types  in  the  P1  envelope  to  undefined  for  that  body  part. 

b)  The  encoded  information  types  of  the  message  being  forwarded  should  be  reflected  in  the 
new  original  encoded  information  types  being  generated. 

c)  See  ammex  B  on  recommended  practices  for  the  use  of  the  delivery  information  as  part  of 
Forwarded  IP-message. 


A.17    Multipart  Body 

It  is  the  intent  of  multipart  bodies  to  allow  for  the  useful  and  meaningful  structuring  of  a  message  that  is 
constructed  using  differing  body  part  types.  For  example,  it  is  not  recommended  that  a  message  made 
up  of  only  IA5  text  should  be  represented  as  a  number  of  IA5  body  parts,  each  one  representing  a 
paragraph  of  text. 
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Annex  B  (informative) 
Recommended  X.400  Practices 

It  is  not  necessary  to  follow  the  reconnnnended  practices  when  claiming  conformance  to  these 
agreements. 


B.I      Recommended  Practices  in  P2 


B.1.1  ORDescriptor 

Vendors  following  the  NIST/OSI  Workshop  guidelines  shall,  whenever  possible,  generate  the  ORName 
portion  of  an  ORDescriptor  in  ALL  IPM  heading  fields. 


B.1.2       ForwardedlPMessage  BodyParts 

ForwardedlPMessage  BodyParts  should  be  nested  no  deeper  than  eight.  There  is  no  restriction  on  the 
number  of  ForwardedlPMessage  BodyParts  at  any  given  depth. 


B.I. 3  Dellverylnformation 

It  is  strongly  recommended  that  Dellverylnformation  be  supplied  in  both  fonA^arded  and  autofonA/arded 
message  body  parts.  Dellverylnformation  is  useful  when  a  message  has  multiple  forwarded  message 
body  parts  because  without  it,  the  EncodedlnformationType(s)  of  the  component  fonA/arded  messages 
cannot  be  deduced  easily.  Delivery  Information  is  useful  for  autoforwarded  messages  because  the 
EncodedlnformationType  of  an  autoforwarded  message  is  "unspecified"  and  the 
EncodedlnformationType(s)  of  the  message  cannot  be  determined  easily  without  it.  Absence  of  the 
EncodedlnformationType(s)  makes  it  difficult  for  a  UA  to  easily  determine  whether  the  message  can  be 
rendered. 


B.2     Recommended  Practices  in  RTS 


B.2.1  S-U-ABORT 

In  the  case  where  S-U-ABORT  indicates  a  temporaryProblem,  reestablishment  of  the  session  should  not 
be  attempted  for  a  "sensible"  time  period  (typically  not  less  than  5  minutes).  In  instances  where  this 
delay  is  not  required  or  necessary,  report  a  localSystemProblem. 
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B.2.2  S-U-EXCEPTION-REPORT 

S-U-EXCEPTION-REPORT  reason  codes  can  be  interpreted  as  follows: 


B.2.2.1 


receiving  ability  jeopardized  (value  1) 


Possible  meaning:  The  receiving  RTS  knows  of  an  impending  system  shutdown. 


B.2.2.2 


local  ss-User  error  (value  5) 


Possible  meaning:  The  receiving  RTS  needs  to  resynchronize  the  session  dialogue. 


B.2.2.3 


irrecoverable  procedure  error  (value  6) 


Possible  meaning:  The  receiving  RTS  has  had  to  delete  a  partially  received  APDU,  even  though  some 
minor  synchronization  points  have  been  confirmed. 


Possible  meaning:  The  receiving  RTS  cannot  handle  the  APDU  (for  example,  because  it  was  too  large) 
^  and  wishes  to  inform  the  sending  RTS  not  to  try  again. 


Possible  meaning:  The  S-ACTIVITY-RESUME  request  specified  a  minor  synchronization  point  serial 
number  which  does  not  match  the  checkpoint  data. 


B.2.3       OSI  Addressing  Information 

For  purposes  of  identifying  an  MTA  during  an  RTS  Open,  OSI  addressing  information  should  be  used. 
This  addressing  information  is  conveyed  by  lower  layer  protocols  and  is  reflected  by  the  calling  and 
called  SSAP  parameters  of  the  S-CONNECT  primitives. 

MTA  validation  and  identification  are  related,  but  separate,  functions.  The  mTAName  and  password 
protocol  elements  of  the  RTS  user  data  should  be  used  for  validation,  rather  that  identification,  of  an 
MTA.  The  RTS  initiator  and  responder  may  independently  require  each  other  to  supply  mTAName  and 
password. 

The  CallingSSUserReference  parameter  of  the  S-CONNECT  primitives  should  only  have  meaning  to  the 
entity  that  encoded  it  and  should  not  be  used  to  identify  an  MTA. 


B.2.2.4 


non  specific  error  (value  0) 


B.2.2.5 


sequence  error  (value  3): 
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B.3     Recommended  Practices  for  ORName 

Table  9  stipulates  that  the  StandardAttributeList  must  contain  either  PrivateDomainName  or 
OrganizationName.  It  is  recommended  that,  for  both  originator  and  recipients  in  a  private  domain,  the 
PrivateDomainName  field  be  used. 

It  is  recommended  that  there  should  be  a  DomainDefinedAttribute  to  be  used  in  addressing  UAs  in 
existing  mail  systems,  in  order  to  curtail  the  proliferation  of  different  types  of  DomainDefinedAttributes 
used  for  the  same  purpose.  The  syntax  of  this  DomainDefinedAttribute  conforms  to  the  CCITT  Pragmatic 
Constraints,  and  thus  has  a  maximum  value  length  of  128  octets  and  a  type  length  of  8  octets,  each  of 
type  Printable  String.  Only  one  occurrence  is  allowed. 

This  DomainDefinedAttribute  has  the  type  name  "ID"  (in  uppercase).  It  contains  the  unique  identifier  of 
the  UA  used  in  addressing  within  the  domain.  This  DomainDefinedAttribute  is  to  be  exclusively  used  for 
routing  within  the  destination  domain  (i.e.,  once  routed  to  that  domain  via  the  mandatory  components  of 
the  StandardAttributeList);  any  other  components  of  the  StandardAttributeList  may  be  provided.  If  they 
conflict  delivery  is  not  made. 

The  contents  of  this  parameter  need  not  be  validated  in  the  originating  domain  or  any  relaying  domain, 
but  simply  transferred  intact  to  the  next  MTA  or  domain. 

Class  2  and  class  3  MTAs  in  a  PRMD  should  allow  administrators  to  decide  the  number  of 
OrganizationalUnits  that  should  appear  in  user  names,  instead  of  imposing  a  software  controlled  limit 
which  is  less  than  four.  This  is  desirable  because  when  two  different  vendors  impose  different  limits  on 
the  number  of  OrganizationalUnits  in  a  name,  it  becomes  difficult  for  the  administrator  to  choose  a 
sensible  naming  scheme. 

There  are  existing  mail  systems  that  include  a  small  set  of  non-Printable  String  characters  in  their 
identifiers.  For  these  systems  to  communicate  with  X.400  messaging  systems,  either  for  pass-through 
service  or  delivery  to  X.400  users,  gateways  will  be  employed  to  encode  these  special  characters  into  a 
sequence  of  Printable  String  characters.  This  conversion  should  be  performed  by  the  gateway 
according  to  a  common  scheme  and  before  insertion  in  the  ID  DDA,  which  is  intended  to  carry 
electronic  mail  identifiers.  X.400  User  Agents  may  also  wish  to  perform  such  conversions. 

It  is  recommended  that  the  following  symmetrical  encoding  and  decoding  algorithm  for  non-Printable 
String  characters  be  employed  by  gateways.  The  encoding  algorithm  maps  an  ID  from  an  ASCII 
representation  to  a  PrintableString  representation.  Any  non-printable  string  characters  not  specified  in  the 
table  are  covered  by  the  category  "other"  in  the  table  below. 

The  principal  conversion  table  for  the  mapping  is  as  follows: 
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Table  B.I  -  Printable  String  to  ASCII  Mapping 


ASCII  Character 

Printable  String  Character 

%  (percent) 

(P) 

e  (at  sign) 

(a) 

!  (excleunation) 

(b) 

"  (quote  mark) 

(q) 

_  (underline) 

(u) 

(  (left  paren. ) 

(1) 

)  (right  paren. ) 

(r) 

other 

(3DIGIT) 

where  3DIGIT  has  the  range  000  to  377  and  is  interpreted  as  the  octal  encoding  of  an  ASCII  character. 

To  encode  an  ASCII  representation  to  a  PrintableString,  the  table  and  the  following  algorithm  should  be 
used: 


IF  current  character  is  in  the  encoding  set 

THEN 

encode  the  character  according  to  the  table 

above 

ELSE 

write  the  current  character; 

continue  reading; 

To  decode  a  PrintableString  representation  to  an  ASCII  representation,  the  table  and  the  following 
algorithm  should  be  used: 


IF  current  character  is  not  "("  THEN 
write  character 

ELSE 

{ 

look  ahead  appropriate  characters; 

IF  composite  characters  are  in  the  above  table  THEN 

decode  per  above  table 
ELSE 

^    write  current  character; 
continue  reading; 


Class  2  and  class  3  MTAs  in  a  PRMD  should  allow  administrators  to  decide  the  number  of 
OrganizationalUnits  that  should  appear  in  user  names,  instead  of  imposing  a  software  controlled  limit 
which  is  less  than  four.  This  is  desirable  because  when  two  different  vendors  impose  different  limits  on 
the  number  of  OrganizationalUnits  in  a  name,  it  becomes  difficult  for  the  administrator  to  choose  a 
sensible  naming  scheme. 
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B.4     Postal  Addressing 

For  domains  wishing  to  support  postal  (or  physical)  delivery  options,  the  following  interim  set  of 
"nationally-defined"  domain  defined  attributes  are  recommended.  The  CCITT  will  define  Standard 
Attributes  in  support  of  physical  delivery  in  its  1988  Recommendations;  this  is  only  an  interim  solution. 

CCITT  will  also  be  addressing  the  services  associated  with  physical  delivery.  This  interim  solution  does 
not  address  the  end-to-end  service  aspects  of  physical  delivery;  in  particular,  the  following  IPM  service 
elements  do  not  currently  extend  outside  of  the  X.400  environment: 

a)  alternate  Recipient  Assignment 

b)  PROBE 

c)  Receipt  Notification  /  Non-Receipt  Notifications 

d)  Grade  of  delivery 

"Delivery"  means  passing  a  message  from  the  MTS  to  the  physical  delivery  system  (PDS),  and  not  to  the 
user  (or  user  agent). 

The  following  three  DDAs  are  recommended  to  be  used  to  specify  a  postal  (or  physical)  address: 

CNTRPC  encodes  the  country  and  postal  code  for  postal  delivery.  The  DDA  value  is  of  the  form 
"Country?Postalcode"  (for  example,  "USA722096").  The  country  field  is  optional,  the  postal  code  is 
optional;  the  separator  ("?")  is  not.  If  both  country  and  postal  code  are  missing,  this  DDA  should  not  be 
specified. 

PDA1  The  country  and  postal  code  fields  are  free-form  text. 

PDA2  These  two  DDA  (signifying  Postal  Delivery  Address  strings  1  and  2)  form  a  256  character  free- 
form  postal  address.  Fields  are  separated  by  a  question  mark  ("?").  There  is  no  implied  separator 
between  PDA1  and  PDA2.  The  meaning  of  the  fields  are  defined  by  each  domain  supporting  the  physical 
delivery  interface.  PDA1  contains  the  first  128  characters,  PDA2  the  next  128  characters.  If  the  PDA 
string  is  less  than  1 28  characters,  PDA2  is  not  used. 

For  example,  if  the  domain  interprets  the  PDA  fields  as  lines,  the  address 

Mr .  John  Smi  th 
Conway  Steel 
123  Main  Street 
Reston  VA  22096 

would  be  encoded  as  follows: 
type      =  "PDAl" 

value    =  "Mr.  John  Smith?Conway  Steel?123  Main  Street?Reston  VA" 
CNTRPC  =  "722096" 
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B.5      EDI  use  of  X.400 


B.5.1       Introduction  and  Scope 

This  is  a  guideline  for  EDI  data  transfer  in  an  X.400  environment  conforming  to  the  NIST  agreements. 
These  recommended  practices  outline  procedures  for  use  in  transferring  EDI  transactions  between 
trading  partner  applications  in  an  attempt  to  facilitate  actual  X.400  implementation  by  EDI  users. 

The  scope  of  this  guideline  is  to  describe  specific  recommendations  for  adopting  X.400  as  the  data 
transfer  mechanism  between  EDI  applications. 


B.5.2  Model 


The  MHS  recommendations  can  accommodate  EDI  through  the  approach  illustrated  below.  Many 
Message  Transfer  (MT)  service  elements  defined  in  the  X.400  recommendations  are  particularly  useful  to 
the  EDI  application. 


x.400  Message  (1  EDI  interchange) 


Envelope 


 =_> 


Content 


MHS  Message 


PI  Control 
Information 


— > 


One 
EDI 

Interchange 


This  diagram  depicts  an  EDI  content  (1  EDI  interchange)  enveloped  by  the  P1  MHS  envelope.  All  the  MT 
Services  defined  in  the  X.400  Recommendations  may  be  used  for  EDI.  However,  it  is  not  required  to 
support  optional  or  non-essential  services  to  exchange  EDI  data  between  EDI  users.  When  an  EDI  user 
submits  an  EDI  Trade  Document  to  the  EDI  User  Agent,  the  ED!  UA  will  submit  the  ED!  content  plus  P1 
envelope  to  the  Message  Transfer  System  (MTS). 
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The  EDI  UA  must  support  the  essential  MT  Services  as  defined  in  these  Agreements;  for  example,  as  a 
minimum,  to  provide  default  values  for  services  not  elected  by  the  EDI  user,  such  as  Grade  of  Delivery. 


NOTE  -  MT  Services  are  not  necessarily  made  available  by  the  EDI  UA  to  the  EDI  user. 


B.5.3       Protocol  Elements  Supported  for  EDI 

The  following  P1  protocol  elements  will  be  used  to  support  EDI  applications: 


B.5.3.1        Content  Type 

For  EDI  applications,  the  content  type  will  be  0  (undefined  content). 


B.5.3.2        Original  Encoded  information  Types 

Any  EST  defined  in  the  X.400  Recommendations  may  be  used  to  specify  the  encoding  of  EDI  content. 
However,  for  ANSI  X12  EDI  applications  in  particular,  it  is  expected  that  the  "undefined"  and  "laSText" 
EiT's  will  normally  be  used,  with  "undefined"  used  to  signify  the  EBCDIC  character  set. 


B.5.4      Addressing  and  Routing 

It  is  anticipated  that  connection  of  some  existing  systems  to  an  X.400  service  for  EDI  purposes  will  be  by 
other  than  X.400  protocols,  at  least  in  the  short  term. 

EDI  messages  entering  the  X.400  environment  will  therefore  need  to  have  X.400  0/R  Names  added  to 
identify  the  origination  and  recipient  trading  partners,  typically  by  means  of  local  directory  services  in  the 
origination  domain  which  will  map  EDI  identifiers/addresses  into  0/R  Names.  Such  0/R  Names  will 
contain  Standard  Attributes  as  defined  in  table  9  and  for  recipient  trading  partners  will  at  least  identify 
the  destination  domain. 

In  the  case  of  trading  partners  outside  the  X.400  environment,  it  is  expected,  however,  that  there  will  be 
cases  where  message  delivery  will  require  the  provision  of  addressing  information  beyond  that  which 
can  be  carried  in  Standard  Attributes.  In  such  cases,  Domain  Defined  Attributes  are  recommended  to  be 
used. 

The  syntax  of  this  DDA  is  as  defined  in  table  9,  with  a  single  occurrence  having  the  type  name  "EDI" 
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(uppercase)  and  a  value  containing  the  identifier/address  of  the  trading  partner.  For  ASC  X12  purposes, 
specifically,  this  value  will  comprise  the  2  digit  interchange  ID  qualifier  followed  by  the  interchange  ID 
(max  15  characters).  Routing  on  this  DDA  shall  only  occur,  if  at  all,  in  the  destination  domain. 


B.6     USA  Body  Parts 

It  is  recommended  that  UAs  can  generate  any  USA  Body  Part,  as  defined  in  clause  5.3.6.2,  and  that  they 
can  receive  such  body  parts  as  well,  reception  of  USA  Body  Parts  does  not  imply  further  processing  by 
the  UA,  but  merely  that  the  body  part  is  made  available,  with  a  indication  of  its  registered  body  part 
identifier,  to  another  process  or  deposition  in  a  file.  Generation  implies  the  reverse  of  this  process. 


B.7     Recommended  Practices  for  Binary  Data  Transfer 

The  capability  to  transfer  binary  data,  such  as  those  generated  by  word /document  processing, 
spreadsheets,  or  graphics  applications  among  X.400  system  is  a  useful  and  desirable  feature.  Many 
messaging  systems  provide  such  capability  today. 

It  is  recommended  that  transfer  of  binary  data  through  1984-based  systems  be  achieved  using  the 
unidentified  BodyPart  in  P2  with  the  ASN1  definition  recaptured  as  follows: 


BodyPart 

::=    CHOICE  { 

[0]   IMPLICIT  lASText 

[14]  IMPLICIT  Unidentified 
::=     OCTET  STRING 

Unidentified 

NOTE  -  the  Unidentified  BodyPart  is  included  in  1984  X.400  Implementor's  Guide,  Version  6,  and  is 
renamed  as  BilaterallyDefinedBodyPart  in  1988  X.400  Series  with  the  same  tag  and  definition. 

Additionally  the  binary  data  can  be  identified  by  a  text  string  in  the  subject  heading  or  in  an  lASText  body 
part  preceding  the  Unidentified  BodyPart. 

When  the  Unidentified  BodyPart  is  present  in  a  P2  message,  the  undefined(O)  bit  of  the  PI 
EncodedlnformationTypes  will  be  set.  If  the  IA5Text  bodypart  is  also  present,  the  IA5text(2)  bit  will  also  be 
set. 

The  binary  data  is  the  raw  data  as  generated  by  user  applications.  Besides  encapsulating  it  for  transfer 
purposes,  X.400  systems  do  not  encode  or  interprete  the  binary  data  in  any  way  further.  How  the  data  is 
encoded  or  decoded  is  defined  by  the  cooperating  user  applications.  How  the  data  is  injected  into  X.400 
systems  or  transferred  out  of  X.400  systems  to  the  user  applications,  or  how  the  user  applications  are 
invoked  to  process  the  data  is  a  local  implementation  issue  and  not  defined. 
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B.S      Recommended  Practice  for  Office  Document  Architecture 
(ODA)  Transfer 

It  is  recommended  that  the  conveyance  of  ODA  documents  through  1984-based  X.400  systems  be 
achieved  using  the  following  schemes: 

B.8.1        ODA  In  P2 

An  ODA  document  will  be  transferred  as  a  single  body  part  with  tag  12,  recaptured  as  follows: 


BodyPart 

::=     CHOICE  { 

[0]  IMPLICIT 

lASText 

oda 

[12]  IMPLICIT 

OCTET  STRING 

...  } 

The  content  of  the  Octet  String  will  contain  a  value  of  type  OdaBodyPart  as  follows: 


OdaBodyPart 

::=     SEQUENCE  { 

OdaBodyPartPar ameter s , 

OdaData  } 

The  Parameters  and  Data  components  are  defined  in  Annex  E  of  CCITT  Recommendation  T.411  (1988) 
(ISO  8613-1). 


B.8.2        ODA  In  PI 

Both  the  undefined  bit  (bit  0)  and  tho  ODA  bit  (bit  10)  of  the  EncododlnformationTypo  will  bo  sot  whon 
an  ODA  document  is  prosont  in  P2.The  undefined  bit  (bit  0)  of  the  EncodedlnformationTypesismustibe 
set  and  the  ODA  bit  (bit  10)  of  the  EncodedlnformationTypes  should  be  set  when  an  ODA  document  is 
present  In  P2.  However,  MTAs  should  be  tolerant  of  messages  containing  ODA  document^  being 
received  with  just  the  undefined  bit  (bit  0)  set,  and  should  still  deliver  the  message. 
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Annex  C  (normative)  

Rendition  of  lASText  and  T61  String  Characters 


C.I      Generating  and  Imaging  lASText 

The  characters  that  may  be  used  in  an  lASString  are  the  graphic  characters  (including  Space),  control 
characters  and  Delete  of  the  IA5  character  repertoire  ISO  646. 

The  graphic  characters  that  nnay  be  used  with  a  guaranteed  rendition  are  those  related  with  positions 
2/0  to  2/2,  2/5  to  3/15,  4/1  to  5/10,  5/15  and  6/1  to  7/10  in  the  basic  7-bit  code  table. 

The  other  graphic  characters  may  be  used  but  have  no  guaranteed  rendition. 

The  control  characters  that  may  be  used  but  have  no  guaranteed  effect  are  a  subset  consisting  of  the 
format  effectors  0/10  (LF),  0/12  (FF)  and  0/13  (CR)  provided  they  are  used  in  one  of  the  following 
combinations: 


CR 

LF 

to  Start  a  new  line 

CR 

FF 

to  start  a  new  page  (and  line) 

LF 

..  LF 

to  show  empty  lines  (always  after  one  of  the 

preceding  combinations). 

The  other  control  characters  or  the  above  control  characters  in  different  combinations  may  be  used  but 
have  no  guaranteed  effect. 

The  character  Delete  may  occur  but  has  no  guaranteed  effect.  The  IA5String  in  a  P2  lASText  BodyPart 
represents  a  series  of  lines  which  may  be  divided  into  pages.  Each  line  should  contain  from  0  to  80 
graphic  characters  for  guaranteed  rendition.  Longer  lines  may  be  arbitrarily  broken  for  rendition.  Note 
that  X.408  states  that  for  conversion  from  IA5Text  to  Teletex,  the  maximum  line  length  is  77  characters. 


C.2     Generating  and  Imaging  T61  String 

For  further  study. 
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Annex  D  (informative)  

Differences  in  Interpretation  Discovered  Through  Testing  of  the  MHS 
for  the  CeBit  1 987  Demonstration 

Several  interworking  problems  were  discovered  through  multi-vendor  testing.  These  problems,  and 
recommendations  for  solutions  to  them  are  discussed  In  this  annex. 


D.I      Encoding  of  RTS  User  Data 

The  password  is  defined  as  an  ANY  in  the  X.400  Recommendations,  and  implementor's  groups  have 
decided  to  use  an  lASString  for  this  field.  There  was  some  confusion  about  what  the  X.409  encoding  for 
this  lASString  would  be,  and  the  correct  encoding  is: 


class : 

context  specific 

form: 

constructor 

id  code: 

1 

length: 

length  of  contents 

contents: 

(primitive  encoding) 

lASString: 

16 

length: 

length  of  contents 

contents : 

the  password  string 

class : 

context  specific 

form: 

constructor 

id  code: 

1 

length: 

length  of  contents 

contents : 

(constructor  encoding)  left  as  an  exercise  for  the  reader 

Implementations  should  be  prepared  to  receive  any  X.409  type  for  the  password  because  of  its  definition 
as  an  ANY. 


D.2     Extra  Session  Functional  Units 

One  vendor  proposed  more  than  the  required  set  of  functional  units  on  opening  the  session  connection, 
and  the  receiver  rejected  the  connection.  All  debate  aside  about  whether  the  initiator  should  have 
proposed  units  outside  of  the  required  set,  or  whether  the  receiver  should  have  rejected  the  connection, 
the  set  of  functional  units  can  be  negotiated  in  a  straightfon^/ard  way.  The  following  is  recommended. 

If  the  initiator  proposes  using  more  than  the  required  set  of  functional  units,  the  responder  should 
specify  the  set  of  functional  units  that  it  would  like  to  use  (which  should  include  the  required  set)  in  the 
open  response.  The  session  implementations  will  automatically  use  the  intersection  of  the  units  proposed 
by  both  sides. 

If  the  initiator  proposes  using  less  than  the  required  set  of  functional  units,  the  responder  should  reject 
the  connection.  Unfortunately,  there  is  not  an  appropriate  RefuseReason  for  rejecting  the  connection,  so 
instead  of  refusing  the  connection  in  the  response  to  the  S-CONNECT,  the  receiver  should  issue  an  S-U- 
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ABORT  with  an  Mr  ...reason  of  protocol  Error.  Note  that  it  is  valid  to  issue  an  S-U-ABORT  instead  of 
responding  to  the  S-CONNECT.  A  problem  report  has  been  submitted  to  the  CCITT  requesting  the 
addition  of  a  RefuseReason  for  this  situation. 

If  the  responder  proposes  using  less  than  the  required  set  of  functional  units,  the  session  connection  is 
established  before  the  initiator  can  check  for  this.  If  too  few  functional  units  have  been  proposed,  the 
initiator  should  abort  the  connection  using  S-U-ABORT,  with  an  abort  reason  of  protocolError. 


D.3     Mixed  Case  in  the  MTA  Name 

The  MTA  name  is  frequently  exchanged  over  the  telephone  when  two  systems  are  being  configured  to 
communicate  with  one  another.  In  one  such  telephone  exchange,  the  casing  of  the  MTA  name  was  not 
specified,  the  MTA  name  consisted  of  both  upper  and  lower  case  letters,  and  one  of  the  implementations 
compared  MTA  names  for  equality  in  a  case  sensitive  manner.  Consequently,  connections  failed  until  the 
problem  was  detected  and  repaired.  It  is  recommended  that  the  MTA  name  be  compared  for  equality  in 
a  case  insensitive  manner,  and  that  the  password  be  compared  for  equality  in  a  case  sensitive  manner. 


D.4     X.410  Activity  Identifier 

The  X.400  Implementor's  Guide  recommends  that  the  activity  identifier  be  X.409  encoded,  but  this  is  only 
a  recommendation  and  not  a  requirement.  Consequently,  receiving  systems  cannot  assume  that  the 
activity  identifier  will  be  X.409  encoded. 


D.5     Encoding  of  Per  Recipient  Flag  and  Per  Message  Flag 

In  the  definition  of  the  PerRecipientFlag  in  X.41 1 ,  there  is  a  statement  that  the  last  three  bits  are 
reserved,  and  should  be  set  to  zero.  It  is  unclear  whether  those  bits  are  unused  in  the  X.409  encoding. 
Receivers  should  accept  encodings  with  either  zero  or  three  unused  bits.  A  problem  report  has  been 
submitted  to  the  CCITT  asking  for  clarification. 

Though  there  is  not  any  statement  in  X.41 1  about  the  last  four  bits  of  the  PerMessageFlag,  some 
vendors  have  encoded  this  with  zero  unused  bits,  and  some  have  encoded  it  with  four  unused  bits.  The 
PerMessageFlag  should  be  encoded  with  at  least  four  unused  bits. 


D.6     Encoding  of  Empty  Bitstrings 

There  are  three  valid  encodings  for  an  empty  bitstring:  a  constructor  of  length  zero,  a  constructor  of 
indefinite  length  followed  by  the  end-of-contents  terminator,  and  a  primitive  of  length  one  with  a  zero 
octet  as  the  value. 
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D.7     Additional  Octets  for  Bitstrings 

Nothing  in  X.409  constrains  an  implementation  from  sending  two,  three,  four,  or  even  more  octets  for  a 
bitstring  that  fits  into  one  octet,  with  the  undefined  bits  set  to  zero.  Note  that  the  number  of  excess 
octets  is  bounded  by  the  pragmatic  constraints  guidelines  of  the  CCITT  X.400  Implementor's  Guide  for 
all  of  the  bitstrings  in  PI. 


D.8     Application  Protocol  Identifier 

If  a  value  other  that  1  is  received  in  the  applicationProtocol  of  the  pUserData  in  the  PConnect,  NIST 
implementations  will  reject  the  connection.  If  CEN/CENELEC  implementations  receive  a  value  other  than 
8883  for  this  field,  they  will  reject  the  connection.  This  is  an  unfortunate  state  of  affairs,  because  if  NIST 
implementations  accept  the  value  of  8883  without  supporting  the  MOTIS  service  elements,  they  would  be 
misrepresenting  themselves.  To  mal<e  matters  worse,  CEPT  uses  a  value  of  1 ,  but  relays  MOTIS 
elements,  which  means  that  MOTIS  elements  will  be  relayed  to  implementations  using  a  value  of  1  to 
demonstrate  that  they  do  not  support  MOTIS.  Work  is  continuing  to  try  to  find  a  solution  that  will  allow 
European  implementations  to  interwork  with  U.S  implementations. 


D.9     Initial  Serial  Number  in  S-CONNECT 

This  should  be  implemented  in  accordance  with  section  3.5.1  E4  of  the  Implementor's  Guide. 


D.10    Connection  Data  on  RTS  Recovery 

It  is  clarified  that  the  ConnectionData  is  identical  in  both  the  S-CONNECT.request  and  the  S- 
CONN EOT. response.  The  value  of  the  ConnectionData  is  the  old  Session  Connection  Identifier. 


D.11    Activity  Resume 

If  an  activity  is  being  resumed  on  a  new  session  connection,  it  is  not  clear  from  X.410  and  X.225  whether 
all  four  of  the  called-ss-user  reference,  the  calling-ss-user  reference,  the  common  reference,  and  the 
additional  reference  information  should  be  specified  in  the  S-ACTIVITY-RESUME,  or  whether  one  of  the 
ss-user-references  should  be  absent.  It  is  also  unclear  whether  the  called-ss-user  reference  should  be 
identical  to  the  calling-ss-user  reference  if  both  are  present.  Consequently,  receivers  should  be  tolerant 
of  this  situation.  Appropriate  problem  reports  will  be  submitted  to  the  CCITT  asking  for  clarification. 

D.I  2    Old  Activity  Identifier 

The  Old  Activity  Identifier  in  S-ACTIVITY-RESUME  refers  to  the  original  activity  identifier. 
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D.I  3    Negotiation  Down  to  Transport  Class  0 

For  European  implementations,  X.410  specifies  that  class  0  transport  must  be  supported.  However,  it  is 
permissible  for  an  initiator  to  propose  a  higher  class  as  the  preferred  class,  provided  that  class  0 
appears  as  the  alternate  class  in  the  T-Connect  PDU.  A  responding  implementation  can  choose  to  use 
either  the  preferred  or  alternate  class,  but  again,  must  be  able  to  use  class  0.  In  other  words,  for  private 
to  private  connections  in  Europe,  class  0  transport  is  required. 

This  conflicts  with  the  NIST  agreements,  since  class  0  is  only  required  if  one  of  the  partners  in  a 
connection  is  an  ADMD. 
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Annex  E  (informative)  

Worldwide  X.400  Conformance  Profile  Matrix 

Y  CONFORMANCE  (E)  implies  a  conformance  problem  for  European  products  in  the  United  States. 

Y  CONFORMANCE  (US)  implies  a  conformance  problem  for  U.S.  products  in  Europe. 
Tlie  A/31 1  profile  is  specified  in  Env  41  202,  the  A/321 1  profile  in  Env  41  201 

No  TTC  protocol  classification  for  RTS  exists. 

The  notation  X/Y  indicates  "X"  for  PRMDs  and  T"  for  ADMDs,  i.e.,  "M/G"  would  be  Mandatory  for 
PRMDs  and  Generatable  for  ADMDs. 


Table  E.I  -  Protocol  Element  Comparison  of  RTS 


RTS  element 

NIST 

A/311 

A/3211 

PROBLEM  Y/N 

PConnect 

M 

M 

M 

N 

DataTransfer Syntax 

M  0 

M  0 

M  0 

N 

n 

M 

PI 

VT 

N 

checkpoints ize 

H 

H 

H 

N 

windowSize 

H 

H 

H 

N 

dialogueMode 

H 

H 

H 

N 

connectdata 

M 

M 

M 

N 

appl i  cat  ionProtocol 

G  1 

H  1 

R  8883 

N 

H  8883 

Connect ionDat a 

Open 

G 

G 

G 

N 

Recover 

G 

H 

G 

N 

Open 

RTSUserData 

G 

G 

G 

N 

Recover 

SessionConnectionID 

G 

G 

G 

N 

RTSUserData 

MTANaiae 

G 

G 

G 

N 

Password 

G 

G 

G 

N 

null 

G 

G 

G 

N 

SessionConnectionID 

CallingUserReference 

M 

M 

M 

N 

ConunonRe  f  e  r  enc  e 

M 

M 

M 

N 

AdditionalRef Info 

H 

H 

H 

N 

PAccept 

G 

G 

G 

N 

DataTransf erSyntax 

M  0 

M  0 

M  0 

N 
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Table  E.I  -  Protocol  Element  Comparison  of  RTS  (concluded) 


RTS  element 

NIST 

A/311 

A/3211 

PROBLEM  ( Y/N ) 

PUserData 

M 

M 

M 

N 

CheckpointSize 

H 

H 

H 

N 

Windows ize 

H 

H 

H 

N 

Connec  t  i  onDa  t  a 

M 

M 

M 

N 

irKeruse 

r' 

c 

RefuseReason 

M 

M 

M 

N 

SSUserData 

G 

G 

G 

N 

(in  S-TOKEN-PLEASE ) 

Abort Information 

6 

G 

G 

N 

(in  S-U-ABORT) 

AbortReason 

H 

H 

H 

N 

ref  lectedPareimeter 

X 

X 

X 

N 
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Table  E.2  -  Protocol  Element  Comparison  of  PI 


PI  Protocol 

NIST 

A/ Jli 

A  /on  T 
A/  J   1 1 

PRUBLEM   ( Y/N ) 

ORname 

otanudruAttriDUCeLilSt 

n 

w 

n 

w 

n 

n 

N  see  Note  4 

Doms.  i  nDe  £  At  t  r  i  bu  t  eL  i  s  t 

X 

X 

X 

Y  See  Note  5 

stanaardAtt riDuteList 

Count ryName 

R 

R 

R 

M 

N 

SO  R 

R 

N 

TOT 
.  121 

TT 

n 

Y  Conformance  (E) 

ther 

X 

Y  Prot  Vio 

Adm 1 n 1 s t r a t 1 onDoma 1 nName 

R 

R 

G 

M 

N 

...  if  PrintableString 

R 

G 

N 

...  if  numericString 

H 

H 

Y  Conformance  (E) 

X.121  Address 

X 

X/R 

X 

Conf(US)See  Note  1 

Terminal  ID 

X 

X/G 

X 

Conf(US)See  Note  1 

P r i va t eDoma i nName 

G 

G 

G 

G 

N 

Organizat ionName 

G 

G 

G 

G 

N 

UnigueUAident i  f ier 

X 

X/G 

X 

Conf(US)See  Note  1 

Per sonalName 

G 

G 

G 

G 

N 

Organizat ionalUnit 

G 

G 

G 

G 

N 

Doma i nDe f i nedAt t r i bu t e 

X 

X 

X 

G 

N 

Type 

M 

M 

M 

M 

N 

Value 

M 

M 

M 

M 

N 

Per sonalName 

Surname 

M 

M 

M 

M 

N 

GivenName 

G 

G 

G 

G 

N 

Initials 

G 

G 

G 

G 

N 

fi 

Y 
A 

Y 
A 

Y 

A 

X  w^oncormdiice  K^) 

GlobalDomainldentif ier 

Count ryName 

M 

M 

M 

M 

N 

Adm i n i s t r a t i onDoma i nName 

M 

M 

G 

M 

Y  Proto  Vio 

PrivateDomainldentif ier 

R/H 

H 

R 

M/X 

N 

MPDU 

UserMPDU 

G 

G 

G 

G 

Y  TTC  required 

MPDU  size  is 

DeliveryReportMPDU 

32K 

G 

G 

G 

G 

N 

ProbeMPDU 

H 

H 

H 

H 

N 
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Table  E.2  -  Protocol  Element  Comparison  of  PI  (continued) 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

UserMPDU 

UMPDUen ve 1 ope 

M 

M 

M 

M 

N 

UMPDUcontent 

M 

M 

M 

M 

N 

UMPDUen ve 1 ope 

MPDUidentif ier 

M 

M 

M 

M 

N 

o  r  i  g  i  na  t  o  r  ORn  ame 

M 

M 

M 

M 

N 

or  i  g  i  na lEncodedTypes 

G 

H 

H 

G 

Y  Conformance 

(E) 

Content Type 

M 

M 

M 

M 

N 

UAcontentID 

H 

H 

H 

H 

N 

Priority 

G 

G 

G 

G 

N 

G 

G 

G 

N 

Defer redDeli very 

X 

X 

X 

X 

N 

PerDomainBilatlnfo 

X 

X 

X 

X 

N 

Recipientlnfo 

M 

M 

M 

M 

Y  TTC  MPDU  32K 

Traceinf ormat  ion 

M 

M 

M 

M 

N 

MOTIS-> 

LatestDelivery 

X 

N 

MOTIS-> 

InternalTracelnfo 

M/P 

P 

N 

UMPDUcontent 

M 

M 

M 

M 

N 

mrUKJ  ±  Uoii  L  X  i.  X  ^  L 

GlobalDomainldent 

M 

M 

M 

M 

N 

lASstring 

M 

M 

M 

M 

N 

PerMessageFlag 

DiscloseRecipients 

H 

a  MT 

H 

H 

Y  Conformance 

(US) 

at 

U 

Y  Conformance 

(US) 

ConversionProhibited 

G 

G 

G 

G 

N 

AlternatRecipAl lowed 

H 

@  MT 

H 

X 

Y  Conformance 

(US) 

at 

U 

? 

Y  Conformance 

(US) 

Cont entReturnReques  t 

X 

X 

X 

X 

MOTIS-> 

redirectionProhibited 

X 

N 

PerDomainBilaterallnfo 

Count ryName 

M 

M 

M 

M 

N 

Adm  i  nDoma  i  nName 

M 

M 

G 

M 

Y  Prot  Vio 

MOTIS-> 

P  r  i  va  t  eDoma  i  nName 

G 

N 

Bilaterallnfo 

M 

M 

M 

M 

N 
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Table  E.2  -  Protocol  Element  Comparison  of  PI  (continued) 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  ( Y/N ) 

Del  i  ver  vRetsortContent 

oriainal  MPDUidpni" 

M 

M 

M 

M 

N 

int A rmAdi  at A  Trace 

X/G 

X 

X 

X 

Y  Conformance  (E) 

UAcontentlD 

G 

G 

G 

G 

N 

ReportedRecipientlnfo 

M 

M 

M 

M 

Y  TTC  256  max 

returned 

H 

H 

X 

X 

Y  Conformance  (E) 

billina  information 

X 

X 

X 

X 

N 

ReportedRecipientlnfo 

recipient  ORncune 

M 

M 

M 

M 

N 

ext^ns i ons Td^nt  i  f  i  pr 

M 

M 

M 

M 

N 

PerReciDientPlaa 

X^       X  Ax^V^  X  k/ X  ^?AJl  W  X  XdU 

M 

M 

M 

M 

N 

LastTraceInf ormat ion 

M 

M 

M 

M 

N 

intendedRecipient 

H 

H 

H 

H 

N 

Supplementarylnfo 

X/H 

X 

X 

X 

Y  Conformance  (E) 

MOTIS-> 

Reass  i  gmnent  Inf  o 

X 

N 

MOTIS-> 

Reassignment Info 

MOTIS-> 

i  n t  endedRec  i  p  i  ent 

M 

N 

MOTIS-> 

reasonForReassigmnent 

H 

N 

LastTraceInf ormat ion 

arrival 

M 

M 

M 

M 

N 

convertedEncInf oTypes 

G 

G 

H 

G 

Y  Conformance  (E) 

Reoor t 

M 

M 

M 

M 

N 

Reoort 

Deliveredlnfo 

G 

G 

G 

— 1 

_r 

N  See  Note  6 

NonDp 1 i  VP  r p d  T n  f o 

G 

G 

G 

N 

Deliveredlnfo 

delivery 

M 

M 

M 

M 

N 

TypeofUA 

R/H 

H 

R 

M/G 

N 

NonDeliveredlnfo 

ReasonCode 

M 

M 

M 

M 

N 

D  i  agnos  t  i  cCode 

H 

H 

H 

H 

N 

MOTIS-> 

UAprof ileldentif ier 

X 

N 

MOTIS-> 

UAprof ileldentif ier 

MOTIS-> 

Content Type 

M 

N 

MOTIS-> 

Encoded I nfoTypes 

M 

N 
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Table  E.2  -  Protocol  Element  Comparison  of  Pi  (continued) 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM   ( Y/N ) 

P  r  obeEn ve 1 ope 

probe 

M 

M 

n 

M 

N 

originator 

M 

M 

M 

M 

N 

Content Type 

M 

M 

M 

M 

N 

IT 

n 

n 

n 

ur 

n 

KI 

or  igineilEncInfoTypes 

\3 

u 

n 

n 

Y  Conformance  (E) 

Tracelnformat ion 

M 

M 

M 

n 

XT 
N 

^^^^         ^\  ^  ^  ^     ^\  k<*  1  9 

FernssSayer  laC| 

V7 

\3 

<j 

KI 

con  u  en  t  LienQ  u  n 

11 

n 

rj 
a 

n 

PerDomainBi lat Inf o 

V" 
A 

X 

X 

X 

N 

Recipient Info 

M 

M 

M 

M 

Y  TTC  256  max 

MOTIS->  InternalTracelnfo 

M/P 

P 

N 

KecipienuxnEo 

Rec i pi entORname 

n 

n 

M 

Extensionldentifier 

M 

M 

M 

M 

N 

PerRecipientFlag 

M 

M 

M 

M 

N 

Expl i  c  i  t Conve  r  s  i  on 

X 

X 

X 

X 

N 

MOTIS->  OriginReqAlternatRecip 

X 

N 

nuTio— >  KeassigmnenLinro 

A 

M 

N 

PerRecipientFlag 

Respons  ibilityFlag 

M 

M 

M 

M 

N 

Repor  t Reques  t 

M 

M 

M 

M 

N 

UserReportRequest 

M 

M 

M 

M 

N 

Tracelnformation 

GlobalDoma  i  nl dent 

M 

M 

M 

M 

N 

DomainSuppliedlnfo 

M 

M 

M 

M 

N 
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Table  E.2  -  Protocol  Element  Comparison  of  PI  (concluded) 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

DomainSuppl led Info 

arrival 

M 

M 

M 

M 

N 

deferred 

X 

X 

X 

X 

N 

action 

M 

M 

M 

M 

N 

( 0=relayed) 

G 

6 

G 

N  Note: 

Re-routing  not 

required. 

(l=rerouted) 

H 

H 

H 

N 

MOTIS->  (2=recipientReassigned) 

H 

N 

converted 

H 

G 

H 

H 

Y  Conformance (US ) 

previous 

H 

G 

G 

X 

Y  Conf ormanr'p  ( UJ?  ^ 

fNote!  G  is 

inconsistent  with 

action  (relayed) 

being  "H.") 

ORname 

Encodedlnformati  onTy pe  s 

BitString 

M 

M 

M 

M 

N    See  Note  3 

G3NonBasicParcuneters 

X 

X 

X 

X 

N 

TelstGxNonBas  icParams 

X 

R 

Y 

Y 

X    v^v^ii  J.  v^i.  luaiiot;  ^  uo  ^ 

Presentat  ionAbi lit  ies 

X 

X 

Y 

Y 

N 

uei.  1  veryKepor  tMFDU 

G 

G 

M 

G 

N 

DeliveryReportEnvelop 

M 

M 

M 

M 

N 

DeliveryReportContent 

M 

M 

M 

M 

N 

DeliveryReportEnvelope 

report 

M 

M 

M 

M 

N 

originator  ORname 

M 

M 

M 

M 

N 

Tracelnformation 

M 

M 

M 

M 

N 

InternalTracelnfo 

M/P 

P 

N 
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Table  E.3  -  Protocol  Element  Comparison  of  P2 


FZ  rTOuOCOX 

MTCT 

n/  .3J.X 

n/  J  Z  X  X 

1 

rKKJDLtcjn    (  X./  iS  } 

UAPDU 

IM  UAPDU 

G 

G 

G 

G 

N 

SR_UAPDU 

X 

X 

X 

X 

N 

IM_UAPDU 

Heading 

M 

M 

M 

M 

N 

Body 

M 

M 

M 

M 

N 

Heading 

IPmessagelD 

M 

M 

M 

M 

N 

Originator  ORname 

R 

R 

R 

M/G 

N 

Author izingUsers 

H 

H 

H 

H 

Y  TTC  16  max 

PrimaryRecipients 

G 

G 

G 

G 

Y  TTC  256  max 

CopyRecipients 

G 

G 

G 

G 

Y  TTC  256  max 

Bl i  ndCopyRec  i  p i  ent 

H 

H 

H 

H 

Y  TTC  256  max 

InReplyTo 

G 

G 

G 

G 

N 

Obsoletes 

H 

H 

H 

H 

Y  TTC  8  max 

(.^rossKecerences 

II 

n 

n 

IT 

n 

IT 
11 

X  xic  o  max 

Subject 

G 

G 

G 

G 

N 

ExpiryDate 

H 

H 

H 

H 

N 

ReplyBy 

H 

H 

H 

H 

N 

Kepxy iousers 

IT 

n 

n 

n 

n 

X   xxv^  max 

Importance 

H 

H 

H 

H 

N 

Sensitivity 

H 

H 

H 

H 

N 

Autoforwarded 

H 

H 

H 

H 

N 

MOTIS->  CirculationList 

X 

N 

MOTIS->  ObsoletingTime 

X 

N 

IPmessagelD 

ORname 

H 

H 

H 

H 

N 

Print ablest ring 

M 

M 

M 

M 

N 

ORdescr  intor 

ORname 

H 

H 

H 

> 

N  See  Note  6 

FreeFormName 

H 

H 

H 

N 

Te 1 ephoneNumbe r 

H 

H 

H 

G 

N 

Recipient 

ORdescriptor 

M 

M 

M 

M 

N 

Report Request 

X 

X 

X 

X 

N 

ReplyRequest 

H 

H 

H 

H 

N 
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Table  E.3  -  Protocol  Element  Comparison  of  P2  (continued) 
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Y 
A 
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A 
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KonReceipt Information 
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u 

u 
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1 

1 

1 

1 
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2 

2 

2 
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MOTIS->      =timeobsoleted  (value) 
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Comments 
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returned 
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Y  Conformance  (E) 

Receipt Information 

Receipt 
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Supplementarylnfo 
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O  IA5  Text 
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O  TLX 

X 

X 

X 
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o  Voice 

X 

X 

X 
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o  G3FAX 

X 

X 

X 

N 

O  TIFO 

X 

X 

X 

N 

O  TTX 

X 

X/H 

X 

Y  Conf(US)See  Note  2 

o  VideoTex 

X 

X 

X 

N 
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X 

X 

X 

N 

o  Encrypted 

X 

X 

X 

N 

o  ForwardedlPmessage 

H 

H 

H 
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o  SFD 

X 

X 

X 

N 

O  TIFI 

X 

X 

X 

N 

MOTIS->  O  ODA 

X 

N 

MOTIS->  o  IS06937  Text 

H 

N 

NOTES 

1  It  should  be  noted  that  the  A/31 1  profile  states:  For  routing  all  ADMDs  should  support  all  Form  1 
Variants  of  0/R  Name.  All  PRMDs  should  support  at  least  Form  1,  Variant  1  form  of  OR  Name. 

2  It  should  also  be  noted  that  the  A/31 1  profile  requires  that  all  ADMDs  should  support  the  reception  of 
Teletex  body  parts  for  delivery  to  their  own  UAEs. 

3  An  A/3211  implementation  may  generate  fwfOTIS  encoded  information  types.  See  6.11. 

4  Only  Form  1  Variant  1  of  0/Rname  shown  for  TTC,  but  TTC  defines  other  forms  and  variants.  Form  1 
Variant  1  recommended  for  PRMDs  and  ADMDs,  Form  1  Variant  2  also  recommended  for  ADMDs. 

5  DDA's  can  be  used  to  specify  recipients  in  any  Japanese  domains  other  than  TTC.  Assignment  of  DDAs 
for  UAs  within  TTC  domains  is  not  recommended. 

6  One  of  [Deliveredlnfo/NonDeliveredlnfo]  must  be  present.  TTC  encodes  this  as  shown.  Other  profiles 
represent  this  by  classifying  both  protocol  elements  as  generatable.  A  similar  situation  exists  with  the  P2 
ORdescriptor. 

7  TTC  is  expected  to  support  IA5  for  some  international  MHS  communications. 
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Annex  F  (informative)  ^  

Interworking  Warnings 

ADMD  name  is  to  be  encoded  as  a  single  space  when  configurations  with  no  ADMD's  are  present.  It 
should  be  noted  that  this  may  change  in  January  1988  so  that  the  ADMD  name  is  encoded  as  a  zero 
length  element  in  such  cases. 

The  NIST  agreements  allow  implementation  to  generate  MPDUs  with  no  body  parts.  Such  MPDUs  will  be 
rejected  by  European-conformant  systems.  (Note  this  situation  may  change  in  January  1988) 

In  order  to  optimize  the  number  of  recipients  you  can  read  and  reply  to,  it  is  advisable  to  be  able  to 
generate  all  standard  0/R  name  attributes. 
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Part  8  1988  Message  Handling  Systems 


0  Introduction 

This  is  an  Implementation  Agreement  developed  by  the  Implementor's  Workshop  sponsored  by  the  U.  S. 
National  Institute  of  Standards  and  Technology  to  promote  the  useful  exchange  of  data  between  devices 
manufactured  by  different  vendors.  This  Agreement  is  based  on,  and  employs  protocols  developed  in 
accord  with,  the  OSI  Reference  Model.  It  provides  detailed  guidance  for  the  implementor  and  eliminates 
ambiguities  in  interpretations. 

This  is  an  Implementation  Agreement  for  Message  Handling  Systems  (MHS)  based  on  both  the  CCITT  X.400 
(1988)  series  of  Recommendations  and  the  similar  (but  not  identical)  ISO  MOTIS  standard  (see  References). 
These  Recommendations  and  Standards  are  referred  to  as  the  base  standards.  The  term  'MHS'  is  used  to 
refer  to  both  sources  where  a  distinction  is  unnecessary.  Similarly,  '1984'  and  '1988'  are  often  used  to 
distinguish  between  the  CCITT  X.400  (1984)  series  of  Recommendations  and  the  later  sources. 

This  Implementation  Agreement  seeks  to  establish  a  common  specification  which  is  conformant  with  both 
CCITT  and  ISO  with  a  view  to: 

a)  Preventing  a  proliferation  of  Incompatible  communities  of  MHS  systems  which  are  isolated  for 
protocol  reasons; 

b)  Achieving  interworking  with  implementations  conforming  to  the  OIW  Stable  Implementation 
Agreements  for  CCITT  1984  X.400-based  Message  Handling  Systems; 

c)  Facilitating  integration  of  other  OSI-based  services  (e.g..  Directory)  within  a  single  real  system. 

This  initial  Implementation  Agreement  is  designed  to  encourage  early  upgrade  of  existing  1984-based 
systems  as  follows: 

a)  To  add  1988  functionality  (Message  Store,  Remote  User  Agent,  etc); 

b)  To  provide  additional  functionality  above  the  minimal  conformant  1988  MHS  defined  in  the 
December  1989  version  of  the  OIW  Implementation  Agreements.  Subsequent  versions  of  this 
Agreement  will  define  such  additional  1988  aspects  as  incremental  enhancements. 

However,  it  is  considered  that  the  OIW  Stable  Implementation  Agreements  for  CCITT  1984  X.400-based 
Message  Handling  Systems  (Part  7)  should  not  be  withdrawn  at  this  stage.  It  is  anticipated  that  X.400  (1 984) 
implementations  will  continue  to  provide  a  viable  alternative  for  applications  that  do  not  require  the  additional 
1988  functionality  for  some  time. 


1  Scope 

This  Agreement  specifies  the  requirements  for  MHS  implementations  based  on  the  1988  MHS  standards. 

This  Agreement  applies  equally  to  Private  Management  Domains  (PRMDs)  and  Administration  Management 
Domains  (ADMDs).  Four  boundary  interfaces  are  specified,  as  illustrated  in  figure  1: 
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a)  Management  Domain  (MD)  to  MD; 


b)  Message  Transfer  Agent  (MTA)  to  MTA  within  a  donriain; 

c)  MTA  to  remote  Message  Store  (MS)  or  User  Agent  (UA); 


d)  MS  to  Remote  UA. 

MHS  protocols  other  than  the  Message  Transfer  Protocol  (P1),  the  Message  Transfer  System  Access 
Protocol  (P3),  the  Interpersonal  Messaging  Protocol  (P2),  and  the  Message  Store  Access  Protocol  (P7)  are 
beyond  the  scope  of  tfiis  Agreement.  Issues  arising  from  the  use  of  other  protocols  are  outside  the  scope 
of  this  document.  This  Agreement  describes  the  services  provided  at  each  Interface  shown  in  figure  1 . 


MHS  implementations  may  be  configured  as  any  single  or  multiple  occurrence  or  combination  of  MTA,  MS 
and  UA,  as  illustrated  in  figure  1 .  It  is  not  intended  to  restrict  the  types  of  system  that  may  be  configured 
for  conformance  to  this  Agreement  (although  it  is  equally  recognized  that  not  all  configuration  types  may 
be  commercially  viable). 


MD 


UA 


MTA 


UA 


MS 


MTA 


PI 


PI 


MTA 


PI 


MS 


P3 


MTA 


MS 


P7 


UA 


P3 


MS  UA 


P3 


P7 


UA 


UA 


Figure  1  -  Scenario  Definition. 


The  1988  MHS  standards  cover  a  wide  and  diverse  range  of  functional  areas,  not  all  of  which  would  be 
relevant  to  every  implementation.  In  order  to  achieve  a  more  precise  definition  of  conformance  requirements 
according  to  the  functionality  supported  by  an  implementation,  and  additionally  to  facilitate  future 
enhancement  of  this  initial  specification,  the  concept  of  Functional  Groups  has  been  introduced. 
Conformance  requirements  for  support  of  Functional  Groups  by  particular  configurations  are  specified  in 
clause  16. 


In  the  context  of  these  agreements,  the  term  "Support"  means  that  the  service  provider  makes  the  element 
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of  service  (and  related  elements  of  protocol)  available  to  the  service  user.  The  service  user  provides 
adequate  access  to  invoke  the  elements  of  service  and/or  makes  information  associated  with  the  service 
element  available.  Additionally,  for  "Not  Defined"  or  "Not  Applicable"  elements,  the  service  provider  is  not 
required  to  make  the  element  available  to  the  service  user.  However,  the  service  provider  should  not  regard 
the  occurrence  of  the  corresponding  protocol  elements  as  an  error  and  should  relay  those  elements. 
Naturally,  protocol  elements  marked  critical  for  submission,  transfer,  or  delivery  must  be  processed 
according  to  the  base  standards. 

The  following  functional  groups  are  covered  by  this  Implementors  Agreement: 

a)  The  MT  Kernel  in  clause  5; 

b)  The  IPM  Kernel  in  clause  6; 

c)  The  Message  Store  in  clause  7; 

d)  Remote  User  Agent  support  in  clause  8; 

e)  Distribution  Lists  in  9.2  (which  are  for  further  study); 

f)  Use  of  Directory  in  9.3; 

g)  MHS  Management  in  clause  10  (which  is  for  further  study); 

h)  Security  in  clause  11; 

i)  The  Physical  Delivery  Access  Unit  in  12.1  (which  is  for  further  study); 
j)  Other  Access  Units  in  12.2  (which  are  for  further  study); 

k)  Conversion  in  clause  13  (which  is  for  further  study); 
I)  Redirection  in  clause  14  (which  is  for  further  study); 
m)  The  EDI  Messaging  Service  in  clause  15  (which  is  for  further  study). 

2     Normative  References 
2.1  CCITT 

Application  Layer  -  MIHS 

CCITT  Recommendation  X.400  (1988),  l\/lessage  IHandling,  System  and  Sen/ice  Overview. 

CCITT  Recommendation  X.402  (1988),  Message  IHandling  Systems,  Overall  Architecture. 

CCITT  Recommendation  X.407  (1 988) ,  Message  tiandling  Systems,  Abstract  Service  Definition  Conventions. 
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CCITT  Recommendation  X.411  (1988),  Message  Handling  Systems,  Message  Transfer  System:  Abstract 
Sen/ice  Definition  and  Procedures. 

CCITT  Recommendation  X.413  (1988),  Message  Handling  Systems,  Message  Store:  Abstract  Sen/ice 
Definition. 

CCITT  Recommendation  X.419  (1988),  Message  Handling  Systems,  Protocol  Specifications. 

CCITT  Recommendation  X.420  (1988),  Message  Handling  Systems,  Interpersonal  Messaging  System. 

CCITT  Recommendation  X.I 21  (1988),  International  Numbering  Plan. 

CCITT  draft  Recommendation  X.435  (June  1990),  Message  Handling  Systems,  EDI  Messaging  System, 
Protocol  Specifications. 

CCITT  draft  Recommendation  F.435  (June  1990),  Message  Handling  Systems,  EDI  Messaging  System, 
Abstract  Service  Definition. 


Application  Layer  -  MHS 

ISO  10021-1  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  System  and  Service 
Oven/lev/. 

ISO  10021-2  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Overall  Arcfiitecture. 

ISO  10021-3  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Abstract  Service  Definition 
Conventions. 

ISO  10021-4  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Message  Transfer  System: 
Abstract  Service  Definition  and  Procedures. 

ISO  10021-5  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Message  Store:  Abstract 
Service  Definition. 

ISO  10021-6  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Protocol  Specifications. 

ISO  10021-7  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Interpersonal  Messaging 
System. 


This  version  oHhe  Implementation  Agreements  for  Message  Handling  Systems  (MHS)  is  underdevelopment. 
It  is  based  on  the  CCITT  X.400  (1988)  Recommendations  and  ISO  MOTIS  (10021,  parts  1-7)  standards,  as 
amended  by  the  MHS  Implementors  Guide,  version  3. 


2.2 


ISO 
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It  is  intended  that  the  Stable  Implementation  Agreements  will  initially  include  an  Agreement  which  specifies 
a  minimal  1988-based  MHS  implementation  and  support  for  Message  Stores  and  Remote  User  Agents,  and 
which  addresses  interworking  with  1 984-l)ased  implementations.  The  remaining  features  specified  in  the 
1988  standards  will  be  covered  in  subsequent  versions  of  this  Agreement. 

This  initial  version  has  not  yet  been  aligned  with  other  MHS  profiles,  so  changes  may  be  necessary  in  the 
future  for  international  harmonization,  (e.g.,  support  for  international  character  repertoires  and  conversion). 

4  Errata 

No  Errata  to  Stable  material  at  this  time. 

5  MT  Kernel 

5.1  Introduction 

This  clause  specifies  the  requirements  for  a  minimal  1988-based  MTS  implementation  (i.e.,  MTA)  which  is 
capable  of  interworking  with  1984-based  MTAs.  The  'base'  MT  Service  specified  in  this  clause  does  not 
include: 

a)  Message  Store  (see  clause  7); 

b)  Remote  UA  (see  clause  8); 

c)  Use  of  Directory  Services  (see  9.3); 

d)  Distribution  Lists  (see  9.2); 

e)  Security  (see  clause  11); 

f)  Interworking  with  Physical  Delivery  systems  or  Specialized  Access  (see  clause  12); 

g)  Conversion  (see  clause  13). 

Such  a  minima!  1988-based  MTA  will  have  the  following  capabilities  in  order  to  achieve  intenA^orking  with 
1984-t)ased  MTAs  and  to  facilitate  migration  to  full  1988  operation: 

a)  It  will  be  protocol-conformant  to  1988  PI; 

b)  It  will  downgrade  1988  PI  to  1984  PI  when  relaying  to  1984-based  MTAs,  as  specified  in  Annex 
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B  of  X.419  (see  clause  5.5); 

c)  It  will  support  both  'normal'  mode  and  'X.410-1984'  ('passthrough')  mode  protocol  stacks  (I.e., 
as  required  by  ISO  and  CCITT  respectively); 

d)  A  conforming  implementation  shall  obey  the  criticality  mechanism  defined  in  the  base  standards. 
The  following  abstract  operations  are  made  critical  for  delivery  for  these  Implementation 
Agreements:  message  token,  content  integrity  check,  and  content  confidentiality  algorithm  Id. 


5.2      Elements  of  Service 

This  clause  specifies  the  requirements  for  support  of  MT  Elements  of  Service  by  an  MTA  conforming  to  the 
MT  Kernel  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  follows: 

Mandatory  (M):  the  Element  of  Service  must  be  supported  and  made  available  to  the  sen/ice  user; 

Optional  (0):  the  Element  of  Service  may  be  supported,  but  is  not  required  for  conformance  to  this 
Agreement; 

Out  of  Scope  (I):  the  Element  of  Service  is  outside  the  scope  of  these  Implementation  Agreements; 

Not  Applicable  (-)  :  the  Element  of  Service  is  not  applicable  in  the  particular  context  according  to 
the  t>ase  standard; 

To  Be  Determined  (*):  the  support  classification  for  the  Element  of  Sen/ice  has  yet  to  be 
determined. 

The  requirements  for  support  of  MT  Elements  of  Service  for  origination  and  reception  and  (where  relevant) 
relaying  are  distinguished.  Elements  of  Service  which  are  new  in  the  1988  MHS  standards  are  indicated  as 
(1988). 

An  MTA  must  support  those  Basic  MT  Elements  of  Service  and  MT  Optional  User  Facilities  defined  in  section 
19  of  X.400  (1988)  as  listed  and  qualified  in  tables  1  and  2. 

Specification  of  dynamic  behavior  in  these  agreements  will  only  be  included  in  those  cases  where  there  is 
an  identified  functional  objective  which  is  not  satisfied  by  the  specification  of  dynamic  behavior  in  the 
corresponding  base  standard (s)  and  where  the  resulting  behavior  does  not  breach  base  standard 
conformance  requirements. 

In  these  exceptional  cases,  there  may  be  situations  where  these  agreements  must  specify  the  dynamic 
behavior  of  an  implementation  as  distinguished  in  annex  0  of  ISO  TR-10  000.  Where  this  occurs,  a  table  of 
dynamic  conformance  requirements  will  be  presented  using  the  classification  scheme  below: 

Mandatory  (M):  The  element  must  be  implemented  although  use  is  not  required  for  conformance 
to  the  base  standard.  The  element  shall  always  be  used  for  conformance  to  these  agreements. 
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Excluded  (X):  This  element  must  either  not  be  implemented,  or  it  must  be  possible  to  prevent  use 
of  the  element. 

NOTE  -  As  stated  in  6.7  of  ISO  TR-1 0  000-1,  restrictions  by  a  profile  on  the  dynamic  conformance 
requirements  of  a  base  standard  are  exceptions,  and  should  only  apply  to  transmission.  Restrictions  should 
not  apply  to  reception.  In  the  case  of  Excluded  options,  it  must  be  possible  to  ensure  that  such  options  are 
not  initiated  or  transmitted.  However,  it  is  still  possible  that  an  implementation  may  receive  an  Excluded  element 
from  an  implementation  which  does  not  conform  to  the  same  profile. 


Table  1  -  MT  Kernel:  Basic  MT  Elements  of  Service 


Element  of  Service 

Origination 

Reception 

Relaying 

Access  Management 

m1 

Ml 

Content  Type  Indication 

M 

M 

Converted  Indication 

M 

M 

M 

Delivery  Time  Stamp  Indication 

M 

Message  Identification 

M 

M 

Non-delivery  Notification 

M 

M 

M 

Original  Encoded  Information 

Types  Indication 

M 

M 

Submission  Time  Stamp  Indication 

M 

M 

User/UA  Capabilities 

Registration  (1988) 

m1 

Notes 

1    A  local  matter  in  the  case  of  collocated  UA/MTA  and/or 
MS/MTA  configurations. 
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Table  2  -  MT  Kernel:  MT  Service  Optional  User  Facilities 


Element  of  Service 

Origination 

Reception 

Relaying 

M 

m2 

02 

Ponvprc; "i  on  Proh i bi  i"  ion 

M 

M 

M 

Ponvp r ci i  on  Proh i b i  i"  i on  in  CasG 

of  TiOc; Q  of   Tn f  ortnA I"  i  on   ( 1  98  8  \ 

0 

0 

0 

T^^^ c^T  y         Fitful  "i  \7<^T*\7 

1^^          JL,  X               l-'C  XX  V  C  X  ^ 

m3 

0 

0 

Do f £i T"r Dp livprv  P^^nppllat'i on 

ijx^  X  \?  X  X           LJs^  xxv^xy    x^aiiVrfT^xx  a  v  x  wxx 

m6 

Dp  1  "i  \7P TV  T\IO"t"  "1  f  "i    A  "h  "i  on 

XJX^  XXVv^Xy      i^V^L.XXX^Mi'ClL'X  V^IX 

M 

M 

M 

M 

M 

ULt    ILXjpall^  1  Oil    nioLvJLy     XIxU  1  Oct  L  X  vJXl 

m4 

T\T .    T*'v"r\a"nc;'i  /^n    P  T"^h  "i  b  "i  t*  oH 

Ui-I     £j  JL^Clllo  X  vjll     irXV.'llXUX  Lc^U 

M^ 

"PvT^l  \  r*\  \'    0on\70  T  c*  1  on 

L^X  X  \<r  X  l.r      V^V.'ll  V  O  X  A  X  Wll 

0 

0 

0 

CtiT of   Dp!  1  \7PT\7   QpI  pot"  i  on 

M 

M 

M 

TTol  C\     "f  OT     Dpi  1  \7PT*\7 

iiw  X  u    X  v,^  X    i^c  XX  V  o  X  y 

1 

M 

Tmril  i  o  i  i"   Convp  r  s  i  on 

X  XII X  X       X  U      \^\w/XX  V  ^  X  ^  X  v^xx 

0 

0 

0 

T.a+'PC't"    Dp!  t\7Pt"\7   DpQirmj^'l"'!  on    ^  1  Q  ft  P 

o 

0 

0 

Multi  Destination  Delivery 

M 

M 

M 

Originator  Requested  Alternate 

Recipient  (1988) 

0 

0 

Prevention  of  Non-delivery 

Notification 

M 

Probe 

M 

M 

M 

Redirection  Disallowed  by 

Originator  (1988) 

M 

M 

Redirection  of  Incoming 

Messages  (1988) 

0 

Requested  Delivery  Method  (1988) 

M 

M 

Restricted  Delivery  (1988) 

0 

Return  of  Content 

0 

0 

0 

Notes 

1  A  local  matter  in  the  case  of  collocated  UA/MTA  and/or 
MS/MTA  configurations. 

2  If  Alternate  Recipient  Assignment  is  supported  on 
reception,  then  support  of  Alternate  Recipient  Allowed  is 
Mandatory  on  reception;  otherwise,  support  of  Alternate 
Recipient  Allowed  is  not  applicable  on  reception. 

3  Support  of  this  MT  Element  of  Service  is  Mandatory  for 
conformance  reasons,  but  may  be  performed  as  a  local 
matter  to  the  originating  MTA. 

4  Support  of  this  MT  Element  of  Service  refers  only  to  the 
delivery  of  DL  expansion  history  and  not  to  the  performing 
of  DL  expansion  (see  clause  9.2). 

5  Support  of  this  MT  Element  of  Service  does  not  imply  the 
capability  to  perform  DL  expansion  (see  clause  9.2). 

6  Messages  should  be  held  in  the  originating  MTA  to  provide 
support  for  this  element  of  service. 

5.3      MTS  Transfer  Protocol  (P1) 

The  requirements  for  support  of  MTS  Transfer  Protocol  (PI)  elements  are  detailed  in  clause  1  of  annex  A. 

8 


Part  8:  1988  Message  Handling  Systems  December  1990  (Stable) 

Support  of  MTS  Transfer  Protocol  application  contexts  by  an  MTA  is  classified  as  in  table  3. 

Table  3  -  Application  Contexts  Classification 


Application  Context 

Support 

mts-transf er-protocol-1984 
mts-transf er-protocol 
mts-transfer 

Mandatory 
Mandatory 
Mandatory 

Use  of  the  underlying  services  to  support  these  application  contexts  is  specified  in  clause  14. 

5.4  MTS  -  APDU  Size 

See  Working  Document. 

5.5  1988/84  Interworking  Considerations 

See  Working  Document. 

6     IPM  Kernel 
6.1  Introduction 

This  clause  specifies  the  requirements  for  a  minimal  1988-based  IPMS  implementation  (i.e.,  UA)  which  is 
capable  of  interworking  with  1984-based  UAs.  The  'base'  IPM  Service  specified  in  this  clause  does  not 
include: 

a)  Message  Store  (see  clause  7); 

b)  Remote  UA  (see  clause  8); 

c)  Use  of  Directory  Services  (see  9.3); 

d)  Distribution  Lists  (see  9.2); 

e)  Security  (see  clause  11); 

f)  Interworking  with  Physical  Delivery  systems  or  Specialized  Access  (see  clause  12). 

Such  a  minimal  1988-based  UA  will  have  the  following  capabilities  in  order  to  achieve  intenworking  with  1984- 
based  UAs  and  to  facilitate  migration  to  full  1988  operation: 

a)  It  will  continue  to  support  content  type  P2  (encoded  as  integer  2)  on  origination  and  reception; 
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b)  It  will  support  receipt  of  P2  (encoded  as  integer  22); 

c)  It  may  originate  P2  encoded  as  integer  22,  but  the  guidelines  specified  in  section  8.18.2  of  X.420 
(1988)  are  to  be  followed,  i.e.  the  content  type  shall  be  encoded  as  integer  2  unless  1988  P2 
protocol  elements  are  present.  All  IPM  UAs  must  support  either  MTS  Submission  and  Delivery 
based  on  the  protocol  classifications  in  clause  3  of  annex  A,  or  MS  Submission  and  Retrieval  based 
on  the  protocol  classifications  in  clause  4  of  annex  A.  However,  how  such  information  is  conveyed 
to/from  the  MTS  or  MS  in  the  case  of  a  collocated  UA  is  a  local  matter,  and  will  not  necessarily  be 
subject  to  conformance  verification. 


6.2      Elennents  of  Service 

This  clause  specifies  the  requirements  for  support  of  IPM  Elements  of  Service  by  a  UA  conforming  to  the 
IPM  Kernel  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Sen/ice  is  as  defined  in  5.2. 

The  requirements  for  support  of  IPM  Elements  of  Service  for  origination  and  reception  are  distinguished. 
Elements  of  Service  which  are  new  in  the  1988  MHS  standards  are  indicated  as  (1988). 

A  UA  must  support  those  Basic  IPM  Elements  of  Service  and  IPM  Optional  User  Facilities  defined  in  section 
19  of  X.400  (1988)  as  listed  and  qualified  in  tables  4  and  5. 


Table  4  -  IPM  Kernel:  Basic  IPM  Elements  of  Service 


Element  of  Service 

Orig 

Recep 

Access  Management 

Ml 

Ml 

Content  Type  Indication 

M 

M 

Converted  Indication 

M 

Delivery  Time  Stamp  Indication 

M 

IP-message  Identification 

M 

M 

Message  Identification 

M 

Non-delivery  Notification 

M 

Original  Encoded  Information 

Types  Indication 

M 

M 

Submission  Time  Stamp  Indication 

M 

M 

Typed  Body 

M 

^1 

User/UA  Capabilities  Registration  (1988) 

Notes 

1    In  the  case  of  a  collocated  UA/MTA  or  collocated 

UA/MS,  the  method  and  extent  to  which  this  Element  of 
Service  is  provided  is  a  local  matter;  it  is  not 
necessarily  testable  in  the  absence  of  support  for  the 
P3  or  P7  protocol. 


I 
1 
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Table  5  -  IPM  Kernel:  IPM  Service  Optional  User  Facilities  (concluded) 


Element  of  Service 

Orig 

Recep 

Restricted  Delivery  (1988) 

0 

Return  of  Content 

0 

Sensitivity  Indication 

0 

M 

Subject  Indication 

M 

M 

Use  of  Distribution  List  (1988) 

0 

Notes 

I   Other  m  Blem^aits  6t  service  are  listed  In  Table  4|| 
-    guppi) r ili;  of  Non-lece i pt  iSot; i f i ca t ion  Request  on 

reception  does  not  require  the  capability  to  generate 
a  non-receipt  notification  in  the  case  of  an 
implementation  in  which  a  non-receipt  condition  cannot 
occur . 

6.3      Interpersonal  Messaging  Protocol  (P2) 

The  requirements  for  support  of  Interpersonal  Messaging  Protocol  (P2)  elements  are  detailed  in  clause  2 
of  annex  A. 


6.4      Body  Part  Support 

This  clause  specifies  the  requirements  for  support  of  IPM  body  part  types  by  a  UA  conforming  to  this 
Agreement. 

The  classification  scheme  for  support  of  IPM  body  part  types  is  as  defined  in  5.2. 

The  requirements  for  support  of  IPM  body  part  types  for  origination  and  reception  are  distinguished.  Body 
part  types  which  are  new  in  the  1988  MHS  standards  are  indicated  as  (1988). 

A  UA  must  support  those  IPM  body  part  types  defined  in  Annex  E  of  X.420  (1988)  as  listed  and  qualified  in 
table  6.  If  an  implementation  supports  a  particular  body  part  type  for  reception,  it  should  also  be  able  to 
support  that  body  part  type  for  reception  if  it  is  part  of  a  forwarded  message. 

Any  basic  body  part  type  that  is  supported  on  reception  must  be  supported  as  integer  encoding  (ASN.1 
context-specific  identifier)  and  as  object  identifier  (externally-defined)  encoding. 

All  body  parts  with  integer-encoded  identifiers  in  the  range  0  up  to  and  including  16K-1  are  legal.  Body  part 
integer-encoded  identifiers  corresponding  to  X.121  country  codes  should  be  interpreted  as  described  in 
figure  4.  These  privately-defined  body  part  types  are  specified  as  an  interim  measure  to  provide  backward 
compatibility  with  1984  MHS  implementations.  For  intenworking  between  UAs  based  on  the  1988  (or  later) 
MHS  standards,  It  is  strongly  recommended  that  the  externally-defined  body  part  be  used  instead. 
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Table  5  -  IPM  Kernel:  IPM  Service  Optional  User  Facilities 


Orig 

Recep 

ai4-orn^'l"p  Rpr'iriipni"   Al lowGd 

0 

_ 

Ali-prna*l"p  PppiDipnt  AssioninGn'k 

0 

All t hnr i  7 i na  Users  Indica'tion 

0 

M 

Aiito— forwarded  Indication 

0 

M 

Blind  Copy  Recipient  Indication 

0 

M 

Body  Part  Encryption  Indication 

0 

M 

Conversion  Prohibition 

M 

M 

Convcrs i on  Proh ibi t i on  in  CdS6  of  Loss  of 

Tnf  rvrTn;^ f  i  nn    M  QfiR  ^ 

X  11 1-  W  X  lUd  %^  X  V./11      \  X  ^  u  u  / 

0 

0 

C*mc*  c   Pp f  p r  pnp  "i  nn   Tnd  i  cat  i  on 

0 

M 

npf prrpd  Dpi i vprv 

1^/^  X  ^  X  X  ^  u    i^/^  XXV  ^  X  y 

M 

DpFprrpd  DpIivptv  Cancpllat ion 

L  o  X  X           x/^  XX  V  ^  X  jr     Vi^aii^ar G  x.  ^  n  v  x  waa 

0 

T^o  1  "1       T \7  Not"  1  f  "1  r'^^  t"  1  on 

lyC  XX  V  %S  X  y      L^V./  L'XXX^CkCX  Wli. 

M 

riiQolo^iirp  oF  Dthpr  Rppi'oi pnt s 

0 

M 

DTj  Exnansion  Historv  Indication  fl988) 

JaJ       A-l«^  ^/ W  X  Xi/AA       AA  X  w  \r              _T              AAX^  X        Vft  V>  X  ^^A  A         ^    ^  ^  W  w  ^ 

M 

nr.  FYri;^nc=i  on    Proh  ihitpd  MQRfi^ 

M 

JUiX^lxy    JJClUtj    J.  iiu  1         L  X 

0 

M 

Exnl i  c  i  t  Convprs  i  on 

0 

Forwarded  IP— messaae  Indication 

X  \^  X  TV  W4  X  \^       \^        X  X         AKI taJ  W4       \^        X  A  A  VaS  X  \^  Vft  w  X  X^AA 

0 

M 

firade  of  Del i verv  Selection 

M 

M 

Hold   for  Deli verv 

0 

ImDlicit  Conversion 

X  All        X  X         X    ^        ^«  Vi/A  A  V         X  w  X  AA 

0 

Importance  Indication 

0 

M 

Incomplete  Copy  Indication  (1988) 

0 

0 

Lanauaae  Indication  fl988) 

XJ^AA  AS^  xA  W4        X^        X  A  AxA  X  \^  W%  W  X  \.^A  A        ^  X^  ^  \J  f 

0 

M 

Latest  Delivery  Designation  (1988) 

0 

Multi— Destination  Delivery 

M 

_ 

Multi— part  Body 

0 

M 

Non— receipt  Notification  Request 

0 

m2 

Obsoleting  Indication 

0 

M 

Originator  Indication 

M 

M 

Originator  Requested  Alternate 

Recipient  (1988) 

0 

Prevention  of  Non-delivery  Notification 

0 

Primary  and  Copy  Recipients  Indication 

M 

M 

Probe 

0 

Receipt  Notification  Request  Indication 

0 

0 

Redirection  Disallowed  by  Originator  (1988) 

0 

Redirection  of  Incoming  Messages  (1988) 

0 

Reply  Request  Indication 

0 

M 

Replying  IP-message  Indication 

M 

M 

Requested  Delivery  Method  (1988) 

M 

Editor's  Note:  This  table  was  renumbered  from  table  25  in  the  X.400  Working  copy  (not  table  24  as  the 
September,  1991,  Plenary  motion  stated). 
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Part  8:  1988  Message  Handling  Systems  December  1990  (Stable) 


Table  6  -  IPM  Kernel:  Body  Part  Types 


Body  Part  Type 

Or  i  g 

Recen 

1  exT, 

M 

M 

Voice 

0 

0 

G3Facsimile 

0 

0 

\  1  i.  t:  V  I 

0 

0 

0 

0 

Videotex 

0 

0 

Encrypted 

0 

0 

Message 

( ForwardedlPMessage ) 

0 

M 

MixedMode 

(TIFl) 

0 

0 

Bi later allyDe fined 

(Unidentified) 

0 

0 

NationallyDef ined 

0 

ExternallyDef ined 

(1988) 

0 

0/M-^ 

PrivatelyDef ined 

(see  figure  4) 

0 

0 

GeneralText 

(1988  -  extended) 

* 

* 

Notes 

1    Any  basic  body 

part  type  that  is  supported 

on 

reception  as  integer  encoding  must  also  be 

supported 

as  object  identifier  encoding.  Support  for 

all  other 

externally  defined  body  parts  is  optional. 
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BodyPart  ::=    CHOICE  { 

ia5-text  [0]  lASTextBodyPart , 

externally-defined  [15]  External lyDef inedBodyPart , 

[234]  UKBodyParts, 

[310]  USABodyParts , 


Where  UKBodyParts  and  USABodyParts  (privately  defined)  are 
defined  as: 

SEQUENCE  {BodyPartNtimber,  ANY} 
BodyPartNvunber  ::=  INTEGER 

These  privately-defined  body  part  types  are  specified  as  an 
interim  measure  to  provide  backward  compatibility  with  1984 
MHS  implementations.     For  interworking  between  UAs  based  on 
the  1988  (or  later)  MHS  standards,  it  is  strongly 
recommended  that  the  externally-defined  body  part  be  used 
instead. 


The  undefined  bit  in  PI  Encodedinf ormationTypes  must  be  set 
when  a  message  contains  a  privately  defined  body  part.  Each 
UA  that  expects  such  body  parts  should  include  undefined  in 
the  set  of  deliverable  EncodedlnformationTypes  it  registers 
with  the  MTA. 

Body  part  numbers  are  interpreted  relative  to  the  body  part 
type  in  which  they  are  used.    OIW  registers  body  part 
numbers  for  privately-defined  formats  within  the  United 
States . 


Figure  4  -  Privately-Defined  Body  Parts. 


7     Message  Store 


7.1  Introduction 

This  clause  specifies  Agreements  for  implementation  of  the  Message  Store  (MS)  Functional  Group.  The  MS 
is  responsible  for  accepting  delivery  of  messages  on  behalf  of  a  single  end-user,  and  retaining  the  messages 
until  the  end-user's  UA  is  able  to  retrieve  them.  Message  submission  and  some  administration  services  are 
provided  via  "pass-through"  to  the  MTS.  Figure  5  illustrates  the  logical  relationship  of  the  MS  to  the  UA  and 
MTS. 
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September  1991  (Stable) 


RETRIEVAL 

DELIVERY 

UA 

MS 

MTS 

"<  

INDIRECT 
SUBMISSION 

-<  

SUBMISSION 

 >- 

ADMINISTRATION 

 >- 

ADMINISTRATION 

-<  >- 

-<  >- 

Figure  5  -  Message  Store  Model. 


The  Agreements  in  this  clause  specify  the  Message  Store's  use  of  the  retrieval,  delivery,  and  administration 
services.  Agreements  on  submission  services  are  specified  in  clause  8,  which  describes  support  for  the 
Remote  UA. 

The  goal  of  the  Agreements  in  this  clause  is  to  define  the  minimal  set  of  features  which  are  necessary  to 
provide  useful  Message  Store  services,  independent  of  the  MTA  implementation  version  (i.e.,  1984  or  1988). 


7.2  Scope 

The  scope  of  the  Agreements  in  this  clause  is  depicted  in  figure  6,  and  is  confined  to  the  services  and 
protocols  between  the  boundaries  shown  (marked  with  asterisks).  Requirements  for  the  UA  and  MTA  are 
addressed  only  to  the  extent  that  they  affect  the  Message  Store  and  Remote  User  Agent  services  and 
protocols.  This  reflects  the  additional  services  required  at  the  UA  to  support  MS  access  and  at  the  MTA  to 
support  a  remote  MS. 


* 

1 
1 

P7 

P3 

* 

1 
1 

UA 

MS 

MTA 

I  I 
I  I 


Figure  6  -  Scope  of  Message  Store  Agreements. 

The  UA,  MS  and  MTA  configuration  is  not  restricted;  any  of  these  components  may  be  collocated,  although 
they  are  depicted  as  logically  separate.  In  the  case  of  a  collocated  UA  and  MS,  a  proprietary  interface  may 
be  used  instead  of  P7.  In  the  case  of  a  collocated  MS  and  MTA,  a  proprietary  interface  may  be  used  instead 
of  P3. 
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7.3      Elements  of  Service 

This  clause  specifies  the  requirements  for  support  of  Elements  of  Service  to  provide  a  Message  Store 
conforming  to  the  Message  Store  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  clause  5.2. 

Support  for  Elements  of  Service  is  specified  in  table  7  both  for  the  Message  Store  itself  and  for  the  User 
Agent. 


Table  7  -  Message  Store:  Elements  of  Service 


Element  of  Service 

UA 

MS 

''•MS  Regi^ti^r'' 

M 

Stored  Message  Deletion 

M 

Stored  Message  Fetching 

M 

M 

Stored  Message  Listing 

M 

M 

Stored  Message  Summary 

M 

M 

Stored  Message  Alert 

0 

0 

Stored  Message  Auto  Forward 

0 

0 

7.4      Attribute  Types  j 

Requirements  for  support  of  the  attributes  used  in  the  Message  Store  are  detailed  in  clauses  8  and  10  of  I 
annex  A.  Clause  8  of  annex  A  specifies  support  for  the  General  Attributes  of  the  Message  Store,  while  clause 
10  of  annex  A  specifies  support  for  the  IPM  Message  Store  Attributes.  j 

There  are  three  classes  of  support  for  General  Attributes  in  the  Message  Store:  Basic,  IPM,  and  EDIMG. 

The  Basic  MS  is  intended  to  support  the  use  of  the  MS  as  a  continuously  available,  reliable  device  (such 
as  a  spooling  entity)  for  receiving,  storing,  and  forwarding  messages  and  reports.  The  Basic  MS  is  not 
required  to  support  any  IPM  or  EDIMG  attributes. 

The  IPM  MS  provides  more  flexible  access  to  the  General  Attributes  as  well  as  supporting  IPM  Attributes. 

IPM  User  Agents  can  make  use  of  either  the  Basic  or  IPM  MS.  j 

Clause  A.10  of  annex  A  is  to  be  read  in  accordance  with  annex  C  of  X.420  (1988).  | 

EDI  UA  can  make  use  of  either  Basic  or  EDI  MS.  Clause  A.  12  of  annex  A  is  to  be  read  in  accordance  with 
annex  C  of  X.435. 
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7.5  Pragmatic  Constraints  for  Attribute  Types 

There  are  no  additional  pragmatic  constraints  for  attribute  types  beyond  tliose  of  the  base  standards. 

7.6  Implementation  of  the  MS  with  1984  Systems 

While  the  Message  Store  is  part  of  the  1988  MHS  standards,  implementation  of  MS  services  with  a  1984  MTA 
is  possible.  In  order  to  interoperate  with  other  1984  MHS  systems,  implementations  with  this  configuration 
should  adhere  to  the  following  guidelines: 
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a)  The  UA  must  generate  1984  P2  PDUs; 

b)  The  UA  must  identify  the  content  protocol  as  integer  2  to  the  MS; 

c)  The  MS  must  be  collocated  with  the  MTA  unless  1988  P3  support  is  provided  on  the  1984  MTA 
as  well. 

To  meet  these  guidelines,  the  UA  may  be  implemented  as  follows: 

a)  The  UA  could  conform  to  X.420  (1984),  with  1988  UA  extensions  for  utilizing  the  MS  services; 

b)  The  UA  could  be  a  1988  UA  with  restrictions  on  protocol  elements  generated  and  by  identifying 
the  content  type  as  integer  2  rather  than  22.  No  1988-specific  elements  should  be  generated. 

Details  of  the  interface  between  the  1988  MS  and  the  1984  MTA  when  collocated  are  beyond  the  scope  of 
these  Agreements. 


7.7      MS  Access  Protocol  (P7) 

The  requirements  for  support  of  MS  Access  Protocol  (P7)  elements  by  an  MS  and  a  remote  MS-user  are 
detailed  in  clause  4  of  annex  A. 

The  requirements  for  support  of  MS  Access  Protocol  (P7)  application  contexts  by  an  MS  and  an  MS-user 
areas  specified  in  clauses  6.1  and  10.1  of  X.419  (1988)  (ISO  10021-6)  with  the  additional  requirement  that 
an  MS-user  must  at  least  support  the  ms-access  application  context,  as  defined  in  table  8. 


Table  8  -  Application  Contexts  Support  for  P7 


Application  Context 

MS 

MS-user 

ms-access 

ms-reli able-access 

Mandatory 
Optional 

Mandatory 
Optional 

Use  of  the  underlying  services  to  support  these  application  contexts  is  specified  in  clause  14. 


7.8      MTS  Access  Protocol  (P3) 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  elements  by  an  MTA  and  an  MS  where  the  MS 
is  not  collocated  with  the  MTA  are  detailed  in  clause  A.3  of  annex  A. 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  application  contexts  by  an  MTA  and  an  MS  in 
such  a  scenario  are  as  specified  in  sections  6.1  and  10.1  of  X.419  (1988)  (ISO  10021-6)  with  the  additional 
requirement  that  a  remote  MS  must  at  least  support  the  mts-access  and  mts-forced-access  application 
contexts,  as  defined  in  table  9. 
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Table  9  -  Application  Contexts  Support  for  P3 


Application  Context 

MTA 

MS 

mts-access 
mts-forced-access 
mts-r el i able-access 
mts-forced-reli able-access 

Mandatory 
Mandatory 
Optional 
Optional 

Mandatory 
Mandatory 
Optional 
Optional 

Use  of  the  underlying  services  to  support  these  application  contexts  is  specified  in  clause  14. 


8     Remote  User  Agent  Support 


8.1  Introduction 

This  clause  specifies  Agreements  for  implementation  of  the  Remote  User  Agent  Functional  Group,  i.e.  for 
support  of  an  IPM  UA  that  is  not  collocated  with  its  MTA. 

-  NOTE  -  Support  of  other  classes  of  UA  is  for  further  study. 

The  goal  of  the  Agreements  in  this  clause  is  to  define  the  minimal  set  of  features  which  are  necessary  to 
provide  useful  Remote  User  Agent  services,  independent  of  the  MTA  implementation  version  (i.e.,  1984  or 
1988). 


8.2  Scope 

The  scope  of  the  Agreements  in  this  clause  is  depicted  in  figure  7,  and  is  confined  to  the  sen/ices  and 
protocols  between  the  boundaries  shown  (marked  with  asterisks).  Requirements  for  the  UA  and  MTA  are 
addressed  only  to  the  extent  that  they  affect  the  Remote  User  Agent  services  and  protocols.  Access  to  a 
Message  Store  by  a  Remote  User  Agent  is  covered  in  clause  7. 


*  * 

I  I 
I  I 


P3 

UA 

MTA 

Figure  7  -  Scope  of  Remote  User  Agent  Agreements 
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This  clause  specifies  the  requirements  for  support  of  Elements  of  Service  for  conformance  to  the  Remote 
User  Agent  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  5.2. 

Support  for  Elements  of  Service  is  specified  both  for  the  MT  Service  (table  10)  and  for  the  IPM  Service  (table 
11),  and  is  in  addition  to  the  support  requirements  specified  in  clauses  5  and  6  if  this  Functional  Group  is 
supported. 


Table  10  -  Remote  User  Agent  Support:  MT  Elements  of  Service 


Element  of  Service 

Origination 

Reception 

Access  Management 

M 

M 

Hold  for  Delivery 

M 

User/UA  Capabilities  Registration 

M 

Table  11  -  Remote  User  Agent  Support:  IPM  Elements  of  Service 

Element  of  Service 

Origination 

Reception 

Access  Management 

M 

M 

Hold  for  Delivery 

M 

User/UA  Capabilities  Registration 

M 

8.4      MTS  Access  Protocol  (P3) 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  elements  by  an  MTA  and  an  MTS-user  (whether 
UA  or  UA/MS)  where  the  MTS-user  is  not  collocated  with  the  MTA  are  detailed  in  clause  A.3  of  annex  A. 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  application  contexts  by  an  MTA  and  an  MTS-user 
In  such  a  scenario  are  as  specified  in  sections  6.1  and  10.1  of  X.419  (1988)  (ISO  10021-6)  with  the 
additional  requirement  that  a  remote  MTS-user  must  at  least  support  the  mts-access  and  mts-forced-access 
application  contexts,  as  defined  in  table  12. 


Table  12  -  Application  Contexts  Support  for  P3 


Application  Context 

MTA 

MTS-user 

mts-access 
mts-forced-access 
mts-reli able-access 
mts-f or ced-r el i able-access 

Mandatory 
Mandatory 
Optional 
Optional 

Mandatory 
Mandatory 
Optional 
Optional 

Use  of  the  underlying  services  to  support  these  application  contexts  is  specified  in  clause  14. 


19 


Part  8:  1988  Message  Handling  Systems 


December  1990  (Stable) 


9 


Naming,  Addressing  &  Routing 


II 


9.1 


Use  of  O/R  Addresses  for  Routing 


Procurers  are  responsible  for  understanding  the  implications  of  routing  requirements  and  capabilities. 


9.2      ORAddress  Attribute  List  Equivalence  Rules 

Two  ORAddresses  are  equivalent  if  each  contains  the  same  set  of  attributes  and  each  attribute  compares 
in  type  and  value. 

The  following  equivalence  rules  apply  when  comparing  a  provided  ORAddress  with  a  collection  of  known 
ORAddresses.  For  example,  in  order  to  perform  delivery  of  a  message  to  a  recipient,  the  MTA  must 
unambiguously  match  the  ORAddress  contained  in  the  message  with  the  known  ORAddresses.  See  X.402 
(1988),  section  18.4,  for  the  base  standard  attribute  equivalence  rules.  The  following  additional  rules  must 
also  be  applied  by  the  delivering  (or  non-delivering)  MTA: 

a)  If  the  provided  ORAddress  is  an  unambiguous  underspecification  of  a  known  ORAddress,  the 
ORAddresses  are  equivalent.  For  example,  if  the  initials  were  omitted,  the  ORAddress  would  still  be 
equivalent.  Under-specification  means  that  some  attributes  that  are  not  present  in  the  provided 
ORAddress  are  present  in  the  known  ORAddresses.  Under-specification  does  not  mean  partial  value 
(e.g.,  substring)  equivalence  when  the  same  set  of  attributes  are  present  in  the  ORAddresses. 

b)  Over-specified  ORAddresses  are  not  equivalent.  Over-specification  means  that  more  attributes 
are  present  in  the  provided  ORAddress  than  are  present  in  the  known  ORAddresses. 

c)  An  ADMD  or  PRMD  name  that  is  all  numeric  but  encoded  as  Printable  String  is  considered  to 
be  equivalent  to  the  same  ADMD  or  PRMD  name,  respectively,  with  the  same  numeric  values 

.        encoded  as  Numeric  String. 


NOTES 


1  An  X.500  Directory  service  may  or  may  not  support  these  matching  rules  for  equivalence. 


2  Operational  equivalence  between  T.61  and  Printable  String  is  for  further  study. 


9.3 


Distribution  Lists 


See  Working  Document. 


9.4      MHS  Use  of  Directory 
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9.4.1  Introduction 

The  MHS  standards  recognize  the  need  of  MHS  users  for  a  number  of  directory  service  elements.  Directory 
service  elements  are  intended  to  assist  users,  their  UAs,  and  MTAs  in  obtaining  information  for  use  in 
submission,  delivery,  and  the  transfer  of  messages. 

NOTE  -  The  MTS  may  also  use  the  directory  service  elements  to  obtain  information,  for  example,  to  be  used 
in  the  routing  of  messages.  This  application  of  the  directory  service  is  not  defined  by  the  base  standards  and 
is  therefore  not  addressed  by  this  Agreement. 


9.4.2       Functional  Configuration 

Two  MHS  functional  entities,  the  IPM  UA  and  MTA,  may  access  the  Directory  service  using  the  Directory 
User  Agent  (DUA).  The  interface  between  the  UA  and  DUA,  or  MTA  and  DUA  is  local  and  not  defined.  The 
interaction  between  the  DUA  and  Directory  System  Agent  (DSA)  is  specified  in  Part  1 1 .  A  collocated  DUA 
and  DSA  is  also  permitted. 


9.4.3  Functionality 

Examples  of  functional  usages  of  directories  have  been  identified  for  UAs  and  the  MTAs  in  conjunction  with 
their  DUAs.  These  are: 

a)  UA  Specific  Functionality: 

1)  Verify  the  existence  of  a  Directory  Name; 

2)  Given  a  partial  name,  return  a  list  of  possibilities; 

3)  Search  the  Directory  for  entries  containing  a  specified  attribute  type  and  value  and 
return  the  Distinguished  Names  of  the  matching  entries; 

4)  Return  the  0/R  Address(es)  that  correspond  to  a  Directory  Name; 

5)  Determine  whether  a  Directory  Name  presented  denotes  a  user  or  a  Distribution  List; 

6)  Return  the  members  of  a  Distribution  List; 

7)  Return  the  capabilities  of  the  entity  referred  to  by  a  Directory  Name; 

8)  Maintenance  functions  to  keep  the  directory  up-to-date,  e.g.,  register  and  change 
credentials; 

b)  MTA  Specific  Functionality: 

1)  Authentication; 

2)  Return  the  0/R  Address(es)  that  correspond  to  a  Directory  Name; 
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3)  Determine  whether  a  Directory  Name  presented  denotes  a  user  or  a  Distribution  List; 

4)  Return  the  members  of  a  Distribution  List; 

5)  Return  the  capabilities  of  the  entity  referred  to  by  a  Directory  Name; 

6)  Maintenance  functions  to  keep  the  directory  up-to-date. 

In  addition  to  functionality,  a  number  of  operational  aspects  must  be  considered.  These  include 
user-friendliness,  flexibility,  availability,  expandability  and  reliability. 


9.4.4       Naming  and  Attributes 

Since  user-friendliness  is  of  primary  importance  in  a  messaging  system,  the  naming  conventions  used  in 
building  the  Directory  Information  Tree  (DIT)  will  impact  the  ability  of  a  user  to  make  intelligent  guesses 
for  Directory  Names. 

It  is  recommended  that  the  naming  guidelines  and  DIT  structures  defined  in  Annex  B  of 
Recommendation  X.521  /ISO  9594-7  be  used  as  the  basis  for  MHS  Directory  Names.  Annex  C  of 
Recommendation  X.402/ISO  10021-2  specifies  further  the  MHS  specific  object  classes.  The  naming  for 
MHS  specific  object  classes  are  recommended  as  follows: 

a)  The  naming  for  mhs-message-store,  mhs-message-transfer-agent,  and  mhs-user-agent  is  that 
of  Application  Entity  in  the  DIT. 

b)  The  naming  attribute  for  mhs-distribution-list  is  commonName.  The  organization, 
organizationalUnit,  organizationalRole,  organizationalPerson,  locality,  or  groupOfNames  can  be 
immediate  superior  to  entries  of  object  class  mhs-distribution-list. 

i      c)  The  naming  for  mhs-user  is  that  of  organizationalPerson,  residentialPerson, 
organizationalRole,  organizationalUnit,  organization,  or  locality. 

NOTE  -  The  mhs-user  object  class  is  a  generic  object  class  which  may  be  used  in  conjunction  with 
another  standard  object  class  for  the  purpose  of  adding  MHS  information  attributes,  such  as  ORAddresses, 
to  a  Directory  entry.  The  means  to  associate  attributes  of  a  generic  object  class  to  an  entry  (or  to  different 
entries)  named  by  a  standard  object  class(es)  is  by  defining  a  new  (un-)registered  object  class,  whose 
superclass(es)  is  that  of  the  naming  object  class(es),  and  of  the  generic  object  class.  E.g.,  to  associate 
mhs-user  attributes  in  the  organizationalPerson  entry,  a  new  unregistered  object  class  can  be  defined  as 
shown  in  figure  8. 


real-user-entry  : 

•=     OBJECT  CLASS 

SUBCLASS  OF  organizationalPerson, 

mhs-user 

Figure  8  -  Example  of  Unregistered  Object  Class  Definition. 


The  MHS  object  classes,  attributes,  and  attribute  syntaxes  that  need  to  be  supported  by  the  Directory 
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In  addition,  tfie  object  classes  organization,  organizationalUnit,  organizationalRole,  organizationalPerson, 
locality,  groupOfNames,  residentialPerson,  and  country  and  tlieir  attributes  and  associated  syntaxes  as 
defined  in  X.520  (ISO  9594,  Part  6)  and  X.521  (ISO  9594,  Part  7)  are  required  to  support  the  MHS. 


I  9.4.5       Elements  of  Service 

I  This  clause  specifies  the  requirements  for  support  of  Elennents  of  Service  for  conformance  to  the  Use  of 
j  Directory  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Setvice  is  as  defined  in  clause  5.2; 

Support  for  Elements  of  Service  is  specified  both  for  the  MT  Service  (table  14)  and  for  the  IPM  Service  (table 
15). 


Table  14  -  Use  of  Directory:  MT  Elements  of  Service 


Element  of  Service 

Origination 

Reception 

Relay 

Designation  of  Recipient  by 
Directory  Name 

M 

M 

Table  15  -  Use  of  Directory:  IPM  Elements  of  Service 


Element  of  Service 

Origination 

Reception 

Designation  of  Recipient  by 
Directory  Name 

M 

9.4.6       Directory  Services 

These  Implementation  Agreements  require  the  Directory  services  as  defined  in  table  16.  Indicated  are  the 
Directory  services  required  to  support  the  needs  of  the  MHS  UA/MTA  and  MHS  Administrator. 


Table  16  -  Directory  Service  Support  Requirements 


Directory  Service 

MHS 
UA/MTA 

MHS 
Admin 

Bind  and  Unbind 

M 

M 

Read 

M 

M 

Compare 

M 

M, 

Abandon 

M 

M 

List 

M 

M 

Search 

M 

M 

Add  Entry 

0 

M 

Remove  Entry 

0 

M 

Modify  Entry 

M 

0 

Modify  RDN 

0 

0 
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9.4.7       OIW  X.400  Base  Directory  Implementation  Agreements 

This  clause  defines  the  X.400  base  Directory  Implementation  Agreements.  Its  structure  and  content  are 
based  on  the  Implementation  Agreements  template  suggested  in  Part  11. 

9.4.7.1  Other  Profiles  Supported 

The  OIW  X.400  Base  Directory  Implementation  Agreements  requires  the  support  of  OIW  Directory  Common 
Application  Directory  Implementation  Agreements  as  defined  in  Part  11. 

9.4.7.2  Standard  Application  Specific  Attributes  and  Attribute  Sets 

The  standard  application  specific  attributes  and  attributes  sets  supported  by  these  Implementation 
Agreements  are  listed  in  table  17.  For  each  attribute  and  attribute  set,  a  reference  is  provided  to  the  standard 
where  it  is  defined. 


Table  17  -  Standard  Attributes  and  Attribute  Sets 


Attribute  /  Attribute  Set 

References 

mhs-deliver able-content-length 

mhs-deliver able-content-types 

mhs-deliverable-eits 

mhs-dl-members 

mhs-dl-submit-permissions 

mhs-mes sage-store 

mhs-or-addr esses 

mhs-prefer red-deli very-methods 

mhs-supported-automatic-act ions 

mhs-supported-content- types 

mhs-supported-optional-at tributes 

X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 

9.4.7.3         Standard  Application  Specific  Object  Classes 

The  standard  application  specific  object  classes  supported  by  these  Implementation  Agreements  are  listed 
in  table  18.  For  each  object  class,  a  reference  is  provided  to  the  standard  where  it  is  defined. 


Table  18  -  Standard  Object  Classes 


Object  Class 

References 

mhs-distribut ion-list 

mhs-mes sage-store 

mhs-mes sage- transfer-agent 

mhs-user 

mhs-user-agent 

X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
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I  9.4.7.4         OIW  Application  Specific  Attributes  and  Attribute  Sets 

There  are  no  application  specific  attributes  or  attribute  sets  defined  by  tliese  Implementation  Agreements. 

9.4.7.5  OIW  Application  Specific  Object  Classes 

;  There  are  no  application  specific  object  classes  defined  by  these  Implementation  Agreements. 

9.4.7.6  Structure  Rules 

i  This  clause  defines  the  naming  and  structure  rules  for  the  MHS  object  classes  which  are  subclasses  of  top. 

j  9.4.7.6.1  MHS  Distribution  List 

Attribute  commonName  is  used  for  naming. 

[  Themhs-distribution-list,  organization,  organizationalUnit,  organizationalRole,  organizationalPerson,  locality, 
!  or  groupOfNames  can  be  immediately  superior  to  entries  of  object  class  mhs-distribution-list. 

:  9.4.7.6.2  MHS  User 

li  The  naming  for  mhs-user  is  that  of  organizationalPerson,  residentialPerson,  organizationalRole, 
j  organizationalUnit,  organization,  or  locality. 

jl  The  organizationalPerson,  residentialPerson,  organizationalRole,  organizationalUnit,  organization,  or  locality 
I  object  classes  can  be  combined  with  the  mhs-user  object  class  to  form  a  new  composite  object  class. 

10  MHS  Management 

j  See  Working  Document. 

11  MHS  Security 
1 1 1 .1  Overview 

f  The  Security  functional  group  is  specified  as  three  security  classes  which  are  incremental  subsets  of  the 
I  security  features  available  in  the  base  standard.  They  are  denoted  as  SO,  S1,  and  S2.  An  implementation 
j  that  conforms  to  the  Security  functional  group  map  support  one  or  more  of  the  security  classes  defined  in 
these  Implementation  Agreements. 

SO:  This  security  class  gathers  together  security  functions  applicable  only  between  MTS-Users. 
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Consequently,  security  mechanisms  are  implemented  witliin  the  MTS-User.  An  MTA  is  required  to 
support  the  syntax  of  the  security  sen/ices  on  submission,  as  the  "Kernel"  supports  the  syntax  on  relay  i 
and  delivery.  The  MTA  is  not  expected  to  understand  the  semantics  of  the  security  services.  | 

Si :  This  security  class  requires  secure  functionality  with  the  MTS-User  and  MTS.  The  MTS  secure  , 

functionality  is  only  required  to  achieve  secure  access  management.  As  with  SO,  most  of  the  security  f 

mechanisms  are  implemented  within  an  MTS-User.  It  primarily  provides  integrity  and  authentication  i 

between  MTS-Users.  However,  MTAs  are  expected  to  support  digital  signatures  for  peer  to  peer  \ 
authentication,  security  labeling  and  security  contexts. 

S2:  This  security  class  is  a  superset  of  S1 ,  adding  security  functions  within  MTAs  and  the  MTS.  The  main  ' 

security  function  added  within  this  group  is  authentication  within  the  MTS,  and,  as  a  consequence,  due  i 

to  the  non-repudiable  nature  of  the  keys  used  for  authentication,  non-repudiation  is  also  added.  ! 

In  addition,  each  of  the  three  security  classes  has  a  variant,  denoted  as  SOa,  Sla,  and  S2a,  which 
mandates  support  of  end-to-end  confidentiality. 

Symmetric  or  asymmetric  techniques  (or  a  combination  thereof)  may  be  used  within  each  security  class  ' 
and  are  identified  by  the  registered  algorithm  identifier. 

Various  levels  of  assurance  in  trusted  COMPUSEC  functionality  may  be  used  within  each  security  class.  ! 
This  is  outside  the  scope  of  this  Implementors  Agreement. 

A  full  rationale  for  each  of  the  security  classes  and  a  broader  discussion  of  security  considerations  are  ; 
provided  in  annex  E. 

Table  19  provides  an  overview  of  the  requirements  made  by  the  security  classes  on  the  MTS-User  and  \ 
MTA.  The  table  entries  are  descriptive,  and  are  not  intended  to  refer  to  security  service  elements. 
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Table  19  -  Overview  of  Security  Requirements  for  Each  Security  Class. 


Class 

Requirements 

MTS-User 

MTA 

Kernel 

Submission,  delivery,  and 
relay  of  EoS 

SO 

Content  Integrity,  Proof  of 
Delivery,  Message  Origin 
Aucnent: ica t ion         to  ua) 

Kernel 

SOa 

SO  plus  Content 
Conf  i  dent  i  al i  ty 

Kernel 

SI 

SO  plus  Message  security 
label.  Message  security 

Services 

Peer  entity  authentication. 
Security  context.  Security 

Message  Security  Label 

Sla 

SI  plus  Content 
confidentiality 

SI 

S2 

SI  plus  Message  Origin 
Authentication  Check,  Probe 
Origin  Authentication  Check, 
Report  Origin  Authentication 
Check,  Proof  of  Submission, 
and,  Non-repudiation 

SI  plus  Message  Origin 
Authentication  Check,  Prove 
Origin  Authentication  Check, 
Report  Origin  Authentication 
Check,  Proof  of  Submission, 
and.  Non-repudiation 

S2a 

Sla  plus  S2 

Sla  plus  S2 

The  incremental  functionality  of  the  security  classes  can  be  represented  diagrammatically  as  shown  in 
figure  9. 


SO 

1 

1 

1 

1 

\ 

SOa 

SI 

1 

1 
1 

\ 

Sla 

S2 

\ 

S2a 

Figure  9  -  Incremental  Functionality  of  the  Security  Classes. 

11.2    Common  Requirements 
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11.2.1      Interworking  Between  Security  Ciasses 

A  security  class  can  be  viewed  as  a  tool  which  can  be  used  to  implement  a  security  policy,  and  is  not  a 
security  policy  in  its  own  right  but  a  component  of  a  security  policy. 

lnterworl<ing  between  implementations  supporting  different  security  classes  can  be  achieved  in  terms  of 
any  common  class(es)  supported.  As  specified  in  the  base  standard,  the  label  of  the  message,  probe  or 
report  must  be  checked  against  the  security  context  by  any  implementation  claiming  conformance  to 
classes  S1,  Sla,  S2,  and  S2a. 

NOTE  ■  Interworking  can  be  iimited  to  messages  of  only  one  security  class  by  defining  a  security  context 
consisting  of  labels  with  security  policy  identifiers  of  only  that  security  class. 

This  profile  defines  security  policy  identifiers  (annex  B,  figure  15)  that  corresponds  to  the  security 
classes  defined  in  this  section.  Such  generic  security  policy  identifiers  only  imply  support  of  the  X.400 
security  services  as  specified  for  these  security  classes  in  this  clause.  No  other  COMSEC  or 
COMPUSEC  functionality  can  be  assumed  by  use  of  such  policy  identifiers.  More  specific  security 
policies  may  be  based  on  one  or  more  of  the  security  classes  in  this  section  but  will  require  use  of 
registered  policy  identifiers. 


1 1 .2.2      Comparison  of  Security  Labels 

The  Security  Content  service  ensures  that  the  message  security  label  matches  at  least  one  of  the  set  of 
labels  specified  in  the  security  content  established  between  the  communicating  MHS  entities. 

An  MTA  which  supports  the  Security  Content  service  shall  as  a  minimum  support  matching  for  equality 
on  the  security-policy-identifier,  security-classification,  and  security-categories  elements  of  the  label. 

NOTE  -  The  basic  support  requirement  is  that  absence  of  an  element  shall  not  be  treated  as  "any  value', 
i.e.,  all  permissible  combinations  of  occurrence  and  value  for  the  elements  of  the  message  security  label 
must  be  elaborated  in  the  security  context. 

Any  other  matching  rules  (e.g.,  covering  the  privacy-mark  element  or  based  on  alternative  methods  of 
comparison)  may  be  used  in  particular  application  scenarios,  but  such  specification  and  usage  will  be 
subject  to  bilateral  agreement  and  will  depend  on  the  security  policy  in  force. 

The  message  security  label  can  be  placed  in  the  per-message  extensions  or  in  the  signed  or  encrypted 
data  of  the  per-recipient  message  token.  It  is  recommended  that  the  integrity  of  the  security  label  is 
protected  by  including  it  in  the  token  signed  data,  or  (if  the  label  Is  in  the  per-message  extensions)  by 
computing  the  message  origin  authentication  check  on  the  message.  (Support  of  MOAC  is  optional  in 
security  classes  SO  and  S1 .)  Which  of  these  labels  is/are  checked  by  the  security  context  service  is 
dictated  by  the  security  policy  in  force.  The  security  policy  should  also  define  any  requirements  on 
allowable  (per-recipient)  label  values  in  the  case  where  the  message  is  addressed  to  multiple  recipients 
(and  thus  has  multiple  tokens). 

A  label  may  also  be  included  in  the  token  encrypted  data  with  (confidential)  end-to-end  semantics. 
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11.2.3      Application  Context 

When  providing  the  peer  entity  authentication  service,  it  is  recommended  that  MTAs  should  not  use  the 
"association-recovery"  procedure  of  RISE  (section  7.8.3  of  X.228).  MTAs  in  the  role  of  sender  should  not 
invoke  this  procedure  and  MTAs  in  the  role  of  receiver  should  not  accept  RT-OPEN  requests  asking  for 
recovery. 

NOTE  -  It  is  permissible  for  the  sending  MTA  to  perform  the  "activity  resumption"  (section  7.8.1  of  X.228) 
on  an  existing,  authenticated  RISE  association  owned  by  this  MTA. 


1 1 .3    Description  of  Security  Classes 

The  sections  to  follow  describe  the  security  classes  within  the  Security  functional  group.  For  each 
security  class,  there  is  a  description  of  the  security  functionalities  provided,  followed  by  a  table  which 
gives  the  classification  for  each  of  the  security  services  required  by  that  class.  Where  the  classification  of 
a  security  service  does  not  change  for  a  higher  security  class,  then  that  security  service  is  not  repeated 
in  the  table  for  the  higher  security  class. 

Figure  10  explains  the  column  headings  used  in  the  security  class  tables.  The  classifications  are  defined 
in  clause  5.2. 


I— 1- 


UA 

MS 

MTA 

MTA 

MS 

UA 

1:  UA/UA 
2:  UA/MS 
3:  MS /MTA 


Legend 

4:  UA/MTA 
5:  MTA/MS 
6:  MTA/MTA 


7:  MTA/UA 

8:  MS/Originating  UA 
9:  MS/Recipient  UA 


Figure  10  -  Security  Interfaces. 

1 1 .4    Security  Class  0  (SO) 


11.4.1      Security  Functionality 

Security  measures  shall  be  provided  by  the  MHS  implementation  in  order  to  provide  the  following: 
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a)  Integrity  of  message  content; 

b)  Authentication  of  the  MTS-User  who  originated  the  message; 

c)  Authentication  of  the  MTS-User  to  whom  the  message  was  delivered. 
This  security  class  mandates  the  above  services  are  provided  by  an  MTS-User. 
There  are  no  requirements  placed  on  the  MTA. 

1 1 .4.2      Security  Services  for  SO 

Security  class  0  (SO)  mandates  the  security  services  listed  in  table  20. 


Table  20  -  Security  Class  0  (SO) 


Security  Interface 

1 

Uri/ 

UA 

2 

KJn/ 

MS 

3 
no/ 
MTA 

4 

TTA  / 

MTA 

5 

MS 

6 

1*1  Xrl/ 

MTA 

7 

MT2V  / 
FIX 

UA 

8 

MQ  / 

UA 

9 

no/ 
UA 

Security  Service 

Origin  Authentication 

Message  Origin  Authentication-"- 
Probe  Origin  Authentication 
Report  Origin  Authentication 
Proof  of  Submission 
Proof  of  Delivery 

M 
M 

^6 

l6 

I 
I 

I 

I 

I 
I 

- 

m4 

- 

Secure  Access  Management 

Peer  Entity  Authentication^'' 
Security  Context 

0 
0 

0 
0 

0 
0 

0 
0 

0 
0 

0 
0 

0 
0 

Data  Confidentiality 

Connection  Confidentiality" 
Content  Confidentiality 
Message  Flow  Confidentiality 

I 

I 

I 

I 

I 

I 

I 

I 

I 

Data  Integrity  Services 
Connection  Integrity° 
Content  Integrity 
Message  Sequence  Integrity-'--'- 

M 
0 

I 

I 

I 

I 

I 

I 

I 

Non-Repudiation 

Non-Repudiation  of  Origin^ 
Non-Repudiation  of  Submission 
Non-Repudiation  of  Delivery^ ' -^^ 

0 
0 

I 

I 

0 

Message  Security  Labelling^ 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Security  Management  Services 
Change  Credentials 
Register 
MS-Register 

0 
0 
0 

0 
0 

0 

l9 

0 
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Table  20  -  Security  Class  0  (SO)  (concluded) 


I  Notes 

I     1    Only  provided  to  the  message  recipient. 

I     2    Using  either  symmetric  or  asymmetric  algorithms  as  identified 
I         by  the  algorithm  identifier  in  the  applicable  protocol  element. 
I     3    When  security  labelling  is  used,  the  security  policy  identifier  shall 
be  included. 

4  If  Proof  of  Delivery  and  Content  Confidentiality  are  both  used,  and 
delivery  is  to  an  MS,  then  proof  of  delivery  can  only  be  computed  on  the 
encrypted  content.  It  should  be  noted  that  this  will  not  provide 
non-repudiation  of  delivery. 

5  Using  either  a  trusted  notary  (symmetric)  or  using  certificates 
tokens  which  are  not  repudiable  (asymmetric). 

6  Corrects  table  7  of  X.402  in  the  base  standard. 

7  Authentication  between  collocated  objects  is  a  local  issue. 

8  Refer  to  section  10  of  X.402  and  ISO/IEC  10  021-2  and  IS  7498-2. 

9  These  services  are  expected  to  be  provided  by  non-standard 
management  services  and  are  therefore  outside  the  scope  of  this 
Implementors  Agreement. 

10  Non-Repudiation  of  Delivery  can  only  be  provided  when  the 
proof -of -deli very  service  is  used. 

11  Allocation  and  management  of  sequence  numbers  is  outside  the 
of  this  Implementors  Agreement  (as  it  is  subject  to  bilateral 
agreements ) . 


11 .5    Security  Class  OA  (SOa) 


11.5.1      Security  Functionality 

Security  measures  shall  be  provided  by  the  MHS  Implementation  in  order  to  provide  the  following: 

a)  Security  Functionality  defined  in  security  class  SO; 

b)  Content  Confidentiality. 


11.5.2      Security  Services  for  SOa 

Security  class  OA  (SOa)  mandates  the  security  services  of  class  SO  plus  those  listed  in  table  21. 


Table  21  -  Security  Class  OA  (SOa) 


Security  Interface 

1 
UA/ 
UA 

2 
UA/ 
MS 

3 
MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 
MS/ 
UA 

9 

MS/ 
UA 

Security  Service 

Data  Confidentiality 

Content  Confidentiality 

M 
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11.6.1  Security  Functionality  | 

Security  measures  shall  be  provided  by  tlie  MHS  implementation  in  order  to  provide  the  following: 

a)  Authentication  of  MTA,  MS,  and  UA; 

b)  Confidentiality  of  connections  between  MTA,  MS,  and  UA; 

c)  Integrity  of  message  content; 

d)  Authentication  of  message  originator; 

e)  Authentication  of  message  delivery  (Proof  of  delivery); 

f)  MLS-features  of  MTA,  MS,  and  UA; 

g)  MLS-separation  of  messages,  probes,  and  reports; 

h)  MLS-mediation  by  secure  access  measures. 
NOTES 

1  The  level  of  assurance  of  the  MLS  trusted  components  is  subject  to  bilateral  agreement. 

2  The  level  of  accountability  provided  is  subject  to  bilateral  agreement. 

11.6.2  Security  Services  for  SI 

Security  class  1  (S1)  mandates  the  security  services  of  class  SO  plus  those  listed  in  table  22. 
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Table  22  -  Security  Class  1  (SI) 


Security  Interface 

1 

UA/ 
UA 

2 
UA/ 
MS 

3 

MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 

MS/ 
UA 

9 

MS/ 
UA 

Security  Service 

Origin  Authentication 

Message  Origin  Authentication2 

Ml 

I 

I 

Secure  Access  Management 

Peer  Entity  Authentication-''* 
Security  Context 

Ml 

Ml 

Ml 

Ml 
Ml 

Ml 

Ml 
Ml 



"i 

Ml 

Data  Integrity  Services 
Content  Integrity 

Ml 

Message  Security  Labelling^ 

Ml 

Ml 

Ml 

Ml 

Ml 

Ml 

Ml 

Ml 

Ml 

Security  Management  Services 
Change  Credentials 
Register 
MS-Register 

M 
M 
M 

M 
M 

M 

l5 

M 

Notes 

1  Shall  always  be  used. 

2  Only  provided  to  the  message  recipient. 

3  Using  either  symmetric  or  asymmetric  algorithms  as  identified  by 
the  algorithm  identifier  in  the  applicable  protocol  element. 

4  Authentication  between  collocated  objects  is  a  local  issue, 

5  These  services  are  expected  to  be  provided  by  non-standard 
management  services  and  are  therefore  outside  the  scope  of  this 
Implementors  Agreement . 

1 1 .7    Security  Class  1 A  (S1  a) 

11.7.1  Security  Functionality 

Security  measures  shall  be  provided  by  the  MHS  implementation  in  order  to  provide  the  following: 

a)  Security  functionality  defined  for  security  class  S1 ; 

b)  Content  Confidentiality. 

11.7.2  Security  Services  for  SI  a 

Security  class  2A  (Si a)  mandates  the  security  sen/ices  of  class  S1  plus  those  listed  in  table  23. 
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Table  23  -  Security  Class  1A  (Sla) 


Security  Interface 

1 
UA/ 
UA 

2 
UA/ 
MS 

3 

MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 

MS/ 
UA 

9 
MS/ 
UA 

Security  Service 

Data  Confidentiality 

Content  Confidentiality 

M 

11.8    Security  Class  2  (S2) 

11.8.1  Security  Functionality 

Security  measures  shall  be  provided  by  the  MHS  implementation  in  order  to  provide  the  following: 

a)  Security  functionality  defined  for  security  class  S1; 

b)  Authentication  and  non-repudiation  of  messages,  probes,  and  reports. 

1 1 .8.2  Security  Service  for  S2 

Security  class  2  (S2)  mandates  the  security  services  of  class  S1  plus  those  listed  in  table  24. 


Table  24  -  Security  Class  2  (S2) 


Security  Interface 

1 
UA/ 
UA 

2 
UA/ 
MS 

3 

MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 

MS/ 
UA 

9 

MS/ 
UA 

Security  Service 

Origin  Authentication 

Message  Origin  Authentication^ 
Probe  Origin  Authentication 
Report  Origin  Authentication 
Proof  of  Submission 

Ml 

M^ 

"J 

M-"- 

Ml 

Ml 

Ml 

M 

Non-Repud  i  a  t  i  on 

Non-Repudiation  of  Origin 
Non-Repudiation  of  Submission 
Non-Repud i at ion  of  Delivery 

m5 
m5 

m2 

m2 

m2 

Notes 

1  Shall  always  be  used. 

2  Using  an  asymmetric  mechanism  (i.e.,  certificates  and  tokens  which 
are  not  repudiable  for  authentication  within  MTAs  and  the  MTS. 

3  Using  the  Message  Origin  Authentication  Check  as  detailed  in  the 
base  standard. 

4  Shall  always  be  used,  and  corrects  table  7  in  X.402. 

5  Using  either  a  trusted  notary  (symmetric)  or  using  certificates 
tokens  which  are  not  repudiable  (asymmetric). 
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1 1 .9    Security  Class  2A  (S2a) 
11.9.1      Security  Functionality 

Security  measures  shall  be  provided  by  the  MHS  implementation  in  order  to  provide  the  following: 

a)  Security  functionality  defined  for  security  class  S2; 

b)  Content  Confidentiality. 


11.9.2      Security  Services  for  S2a 

Security  class  2A  (S2a)  mandates  the  services  of  class  S2  plus  those  listed  in  table  25. 

Table  25  -  Security  Class  2A  (S2a) 


Security  Interface 

1 
UA/ 
UA 

2 

UA/ 
MS 

3 

MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 
MS/ 
UA 

9 

MS/ 
UA 

Security  Service 

Data  Confidentiality 

Content  Confidentiality 

M 

I  12  Specialized  Access 

'  See  Working  Document. 

I  13  Conversion 

I  See  Working  Document. 

i 

!  14  Redirection 

II 

'  See  Working  Document. 

1 

1  15  EDI  Messaging  Service 

I  See  Working  Document. 
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16   Use  of  Underlying  Layers 


16.1     MTS  Transfer  Protocol  (PI) 

The  P1  protocol  is  mapped  onto  the  Reliable  Transfer  Service  Element  (RTSE)  either  in  X.410-1984  mode 
or  in  norma!  mode,  as  specified  in  clause  5.3.  In  X.410-1984  mode,  the  RTSE  makes  direct  use  of  the 
sen/ices  provided  by  the  Session  Layer,  as  specified  in  Part  5  (Upper  Layers)  of  the  Stable  Implementation 
Agreements.  In  normal  mode,  the  RTSE  makes  use  of  the  services  provided  by  the  Association  Control 
Service  Element  (ACSE)  and  Presentation  Layer,  as  defined  in  Part  5  (Upper  Layers)  of  these  Agreements. 


16.2    MTS  Access  Protocol  (P3)  and  MS  Access  Protocol  (P7) 

The  P3  and  P7  protocols  make  use  of  the  services  provided  by  the  Remote  Operations  Service  Element 
(ROSE),  Association  Control  Service  Element  (ACSE),  Presentation  Layer,  and,  optionally,  the  Reliable  j 
Transfer  Service  Element  (RTSE),  as  defined  in  Part  5  (Upper  Layers)  of  these  Agreements.    It  is 
recommended  that  RTSE  be  used  for  recovery  purposes  when  the  implementation  does  not  use  Transport 
Class  4  or  there  is  a  high  probability  of  an  association  failure. 


17   Error  Handling 

This  clause  describes  appropriate  actions  to  be  taken  upon  receipt  of  protocol  elements  which  are  not 
supported  in  these  Implementation  Agreements:  malformed  PDUs,  unrecognized  0/R  Name  forms,  content 
errors,  errors  in  reports,  and  unexpected  values  for  protocol  elements. 

An  implementation  must  be  able  to  report  all  error  conditions  which  may  occur  with  the  appropriate  error 
information  as  defined  in  the  referenced  base  standards.  An  implementation  must  be  able  to  handle  receipt 
of  all  error  indications  which  are  defined  in  the  referenced  base  standards.  An  implementation  must  also 
be  tolerant  of  any  additional  error  indications  which  are  not  currently  defined,  but  is  not  required  to  be  able 
to  interpret  such  error  information. 


17.1     PDU  Encoding 

See  Working  Document. 


17.2  Contents 

See  Working  Document. 
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17.3  Envelope 

See  Working  Document. 


17.4  Reports 

See  Working  Document. 


17.5    Pragmatic  Constraints 

See  Working  Document. 


1 8  Conformance 

For  this  clause,  the  term  conformance  is  as  defined  in  ISO  9646. 

Bilateral  agreements  between  domains  may  be  implemented  in  addition  to  the  requirements  stated  in 
this  document.  Conformance  to  this  Agreement  requires  the  ability  to  exchange  messages  without 
use  of  bilateral  agreements. 

In  order  to  achieve  a  more  precise  definition  of  conformance  requirements  according  to  the  functionality 
supported  by  an  implementation,  the  concept  of  Functional  Groups  has  been  introduced.  A  Functional 
Group  is  a  set  of  related  Elements  of  Sen/ice  and  associated  protocol  elements  which  provide  a  discrete 
area  of  functionality. 

Conformance  to  this  Agreement  requires  as  a  minimum  that  all  Mandatory  Elements  of  Service  listed  in 
this  Part  are  supported  in  the  manner  defined  in  the  MHS  standards,  as  qualified  in  this  Agreement,  for 
each  of  the  Functional  Groups  claimed.  Any  Optional  Elements  of  Service  for  which  support  is  claimed 
must  also  be  supported  as  defined  in  the  MHS  standards  and  as  qualified  in  this  Agreement.  Pragmatic 
constraints  shall  be  observed  as  specified  in  the  CCITT  X.400  (1988)  Series  of  Recommendations.  It  is 
not  necessary  to  implement  the  recommended  practices  of  annex  D  in  order  to  claim  conformance  to 
this  Agreement. 

Conformance  requirements  for  support  of  Functional  Groups  by  particular  configuration  types  (see 
clause  2)  are  listed  in  table  32.  An  implementation  may  claim  conformance  to  multiple  configuration 
types  (e.g.,  "MTA+UA"  and  "Class  B  MTA  only"). 
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Table  32  -  Conformance  Requirements 


Functional  Group 


MT  Kernel 

IPM  Kernel 

Message  Store* 

Remote  UA 

Distribution  List 

Directory 

MHS  Management 

Security 

Physical  Delivery 
Other  Access  Units 
Conversion 
Redirection 
EDI  Messaging 


Configuration-^ 


MTA 
+  2 


M 

O 
O 
0 
* 

0 
* 

* 
* 


MTA 

+ 
MS 


M 

M 

0 

0 

0 
* 

o 

* 
* 
* 


MTA  Only-^ 


M 


O 

0 
* 

0 
* 

* 

* 


B 


M 


M 

O 

0 
* 

o 

* 
* 
* 

* 


M 


O 

O 

* 

o 

* 
* 
* 
* 
* 


MS 
+ 

UA 


M 

M 

* 

O 
* 

0 

* 

* 


MS 
Only 


M 


0 
* 

0 
* 

* 

* 

* 


UA  Only 


P7  P3 


M 
M 


O 
* 

O 
* 
* 
* 
* 
* 


M 

M 
* 

O 
* 

O 
* 
* 
* 
* 
* 


Notes 

1  There  are  three  conformance  levels  defined  for  the 
MT  Kernel  in  clause  18.1. 

2  Optional  elements  of  the  IPM  Kernel  need  not  be 
supported  in  the  MT  Kernel  in  this  configuration,  for 
example  Probe  and  Deferred  Delivery  Cancellation. 

3  The  designation  of  a         in  a  configuration  (e.g., 
'MTA+MS')   implies  that  there  is  no  exposed  protocol  in 
the  interface  between  the  two  components. 

4  There  are  two  conformance  levels  defined  in  clause 
18.2  for  MS  support. 


18.1     MT  Kernel  Conformance  Levels 

The  MT  Kerne!  conformance  levels  are: 

a)  A  class  'A'  MT  Kernel  implementation  conveys  a  message,  probe,  or  report  to  another  MT 
Kernel  using  standard  means.  A  class  'A'  MT  Kernel  is  specifically  implemented  in  order  to 
transfer  messages,  probes,  and  reports  which  have  previously  been  transferred  and  need  not 
support  submission  and  delivery.  A  class  'A'  MT  Kernel  may  perform  other  activities  such  as 
originate  reports,  expand  distribution  lists,  and  perform  conversions. 

b)  A  class  'B'  MT  Kernel  implementation  supports  submission,  delivery,  and  transfer  using 
standard  means,  i.e.  P3  and  P1.  A  class  'B'  MT  Kerne!  need  not  support  the  transfer  of 
previously  transferred  messages,  probes,  or  reports. 

c)  A  class  'C  MT  Kerne!  implementation  requires  support  for  transfer  of  messages,  probes,  and 
reports  to  another  MT  Kerne!  using  standard  means.  A  class  'C  MT  Kernel  does  not  require 
support  for  the  transfer  of  previously  transferred  messages,  probes,  and  reports,  and  message 
submission  and  delivery  is  achieved  by  non-standard  means. 
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An  MTA  may  conform  to  one  or  more  of  the  MT  Kernel  classes.  For  example,  a  class  'B'  or  'C  MT 
Kernel  which  supports  the  transfer  of  previously  transferred  messages,  probes,  and  reports  is  also 
conformant  to  a  class  'A'  MT  Kernel.  Figure  1 1  illustrates  several  combinations  of  MT  Kernel 
conformance  classes.  Additional  combinations  are  possible. 


UA 


MS 


MTA 
Class  B 


MTA 
Class  A 


MTA 
Class  AB 


Standard 
Non-standard 


UA 


MS 


MTA 
Class  C 


UA 


MS 


Figure  1 1  -  MT  Kernel  Conformance  Classes 

18.2    MS  Conformance  Levels 

The  MS  conformance  levels  are: 

a)  A  Basic  MS  only  requires  support  for  the  General  Attributes  as  specified  in  clause  8  of  annex 
A; 

b)  An  IPM  MS  requires  support  from  both  the  General  Attributes  and  IPM  Attributes  as  specified 
in  clauses  8  and  10,  respectively,  of  annex  A. 


19  Management  Domain  Agreements 

See  Working  Document. 


39 


Part  8:  1988  Message  Handling  Systems 


December  1990  (Stable) 


Annex  A  (normative) 

MHS  Protocol  Specifications 

Tables  34  through  49  specify  the  requirements  for  support  of  MHS  protocol  elements  for  conformance  to 
this  Agreement.  It  should  be  noted  that  the  tables  specify  minimum  support  for  conformance  to  the 
relevant  Kernel  functional  groups  and  where  appropriate  also  specify  enhanced  support  requirements 
where  one  or  more  further  functional  groups  are  claimed.  All  element  support  Is  subject  to  further 
review  and  may  be  upgraded  In  later  versions  of  this  Agreement 

Within  the  classification  tables  (34-49),  the  column  "S"  indicates  the  classification  from  the  base 
standards.  This  is  provided  for  reference  purposes  only  and  is  intended  to  be  in  agreement  with  the  base 
standards. 

The  protocol  support  classification  scheme  used  in  this  version  of  this  Agreement  is  described  below. 
However,  it  should  be  noted  that  the  scheme  is  currently  under  review  both  within  the  OIW  X.400 
S!G  and  in  the  EWOS/ETSI  MHS  groups  and  is  likely  to  be  revised  for  later  versions  of  this 
Agreement. 

The  classification  of  support  for  a  protocol  element  specifies  the  requirements  for  implementations 
conforming  to  this  Agreement  to  be  able  to  generate,  receive  and  process  that  protocol  element,  as 
appropriate  (the  'receiving'  role  includes  relaying  where  appropriate).  The  classification  of  support  for 
each  protocol  element  is  relative  to  that  for  its  containing  element.  Where  sub-elements  within  a 
containing  element  are  not  listed,  then  their  support  classification  shall  be  assumed  to  be  that  of  the 
containing  element.  Where  the  range  of  values  to  be  supported  for  an  element  is  not  specified,  then  all 
values  defined  in  the  base  standard  shall  be  supported. 

The  classifications  have  been  revised.  The  new  classifications  relate  to  the  classifications  in  the  Part  7  of 
the  Stable  Agreements  as  shown  in  table  33. 


Table  33  -  Classification  Changes 


Former 
Category 

New 

Originator 
Category 

Recipient 
Category 

Generatable  (G) 
Supported  (H) 
Mandatory  (M) 
Required  (R) 
Unsupported  (X) 

Mandatory  (M) 
Optional  (0) 
Mandatory  (M) 
Mandatory  (M) 
Optional  (0) 

Mandatory  (M) 
Mandatory  (M) 
Mandatory  (M) 
Mandatory  (M) 
Optional  (0) 

The  support  classifications  are  stated  for  both  Origination  and  Reception  (0/R)  in  the  following  tables 
(34-49).  The  defined  support  for  each  is  stated  within  each  classification. 

Implementations  conforming  to  this  Agreement  must  be  capable  of  accepting  the  syntax  of  every 
protocol  element  of  a  protocol  for  which  support  is  claimed.  When  an  MS  or  MTA  receives  a  protocol 
element  that  according  to  the  base  standard  should  be  conveyed  to  another  MHS  entity  (MTA,  MS,  or 
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UA),  the  MS  or  MTA  is  required  to  preserve  tlie  semantics  of  tliat  protocol  element  in  the  PDU 
conveyed.  Notwithstanding  the  above,  criticality  must  be  observed  according  to  the  base  standard. 

Mandatory  (M)  on  Origination:  Implementations  conforming  to  this  Agreement  shall  generate  this 
element  in  all  information  objects  in  which,  according  to  the  base  standards,  it  shall  occur. 

Mandatory  (M)  on  Reception:  Implementations  conforming  to  this  Agreement  shall  process  this 
element  appropriately  according  to  its  semantics. 

Optional  (O)  on  Origination:  Where  this  element  Is  not  conveyed  from  one  MHS  entity  to 
another,  implementations  conforming  to  this  Agreement  may  optionally  be  capable  of  generating 
this  protocol  element,  but  are  not  required  to  do  so. 

Optional  (O)  on  Reception:  Implementations  conforming  to  this  Agreement  may,  but  are  not 
required  to  be  capable  of  processing  this  protocol  element. 

NOTE  -  Some  protocol  elements  may  not  be  conveyed,  if  dow/ngrading  rules  are  applied. 

To  Be  Determined  (*):  the  support  classification  for  this  protocol  element  has  yet  to  be 
determined. 

Not  Applicable  (-):  The  protocol  element  is  not  applicable  in  the  particular  context  according  to 
the  base  standard. 

Where  the  dynamic  behavior  of  protocol  elements  need  to  be  specified,  the  following  classification 
scheme  is  used: 

Mandatory  (m):  The  protocol  element  shall  always  be  implemented  and  generated.  On  reception, 
correct  action  shall  be  taken  as  specified  in  the  base  standard,  or  as  qualified  or  specified  in 
these  Agreements.  Absence  of  the  corresponding  protocol  element  shall  cause  the  appropriate 
abstract  error  to  be  generated. 

Excluded  (x):  The  protocol  element  shall  not  be  present  or  it  must  be  possible  to  prevent  its  use. 
Its  presence  shall  cause  the  appropriate  abstract  error  to  be  generated. 

Dynamic  conformance  classifications  are  indicated  in  a  single  column  of  each  of  the  Protocol  Element 
tables.  The  classification  applies  to  the  usage  only  of  the  protocol  elements  which  have  a  static 
classification. 


A.1      MTS  Transfer  Protocol  (PI) 


41 


Part  8:  1988  Message  Handling  Systems  December  1990  (Stable) 


Table  34  -  Classification  of  the  PI  Protocol  Elements 


MTS  Transfer  Protocol  (PI) 

Part    1  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

MTABind 

M 

M/M 

M/M 

MTABind 

MTAUnbind 

M 

M/M 

M/M 

MTSE 

See  protocol  elements 

MessageTransf er 

M 

M/M 

M/M 

ProbeTransf er 

M 

M/M 

M/M 

Reoort Transfer 

M 

M/M 

M/M 

Arguments /Results 

MTABind 

ARGUMENT 

<NULL> 

0 

0/M 

0/M 

See  Note  2 

<SET> 

0 

M/M 

M/M 

1  ni  "h  1  a "1" or— n;^ TIP 

M 

M/M 

M/M 

initiator-credentials 

M 

M/M 

M/M 

simple 

0 

M/M 

M/M 

strong 

0 

0/0 

0/0 

secur  i  ty-cont ext 

0 

0/0 

0/0 

RESULT 

<NULL> 

0 

0/M 

0/M 

See  Note  2 

<SET> 

0 

M/M 

M/M 

responder-name 

M 

M/M 

M/M 

responder-credentials 

M 

M/M 

M/M 

simple 

0 

M/M 

M/M 

strong 

0 

0/0 

0/0 

Notes 

1    The  MT  Kernel  implementation  classes  are  defined  in 

clause  16. 

2    The  action  to  be  taken  on  receipt  of  null  MTABind 

authentication  is  that  an  implementation  must  understand  the 

semantics,  but  the  form  of  authentication  that  is  acceptable 

is  a  local  matter. 
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Table  34  -  Classification  of  the  PI  Protocol  Elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part     2  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

MTS-APDU 

message 

M 

M/M 

0/M 

envelope 

M 

M/M 

M/M 

MessageTransferEnvelope 

content 

M 

M/M 

M/M 

See  P2  -  else  undefined 

probe 

M 

M/M 

0/M 

ProbeTransf erEnvelope 

report 

M 

M/M 

M/M 

envelope 

M 

M/M 

M/M 

ReportTransf erEnvelope 

content 

M 

M/M 

M/M 

ReportTransf erContent 

MessageTransferEnvelope 

message-identifier 

M 

M/M 

M/M 

MTSIdentif ier 

originator-name 

M 

M/M 

M/M 

ORName 

or iginal-encoded-informat ion- 

types 

0 

M/M 

0/0 

EncodedlnformationTypes 

content- type 

M 

M/M 

M/M 

built-in 

0 

M/M 

0/0 

external 

0 

0/M 

0/0 

content-identifier 

0 

0/M 

0/0 

priority 

0 

M/M 

0/M 

All  values 

per-message- indicators 

0 

M/M 

0/M 

disclosure-of -recipients 

0 

0/M 

0/M 

implicit-conversion-prohibited 

0 

M/M 

0/M 

alternate-recipient-allowed 

0 

M/M 

0/0 

content-return-request 

0 

0/0 

0/0 

defer red-deli very-time 

0 

0/0 

0/0 

per-domain-bi lateral- 

information 

0 

0/0 

0/0 

PerDomainBi lateralinf o 

trace-information 

M 

M/M 

M/M 

Traceinf ormat  ion 

extensions 

0 

M/M 

M/M 

ExtensionField 

recipient-reassignment- 

prohibited 

0 

M/M 

M/M 

dl-expans ion-prohibited 

0 

M/M 

0/M 

conver s  ion-wi  th-loss- 

prohibited 

0 

0/M 

0/M 

XCILVo  Ur^U^XX  VcLy^U  X  lllo 

n 
\j 

See  X.411 

,  14.1.1  note  2 

originator-return-address 

0 

0/0 

0/0 

originator-certificate 

0 

0/0 

0/0 

content-confidentiality- 

algorithm-identifier 

0 

M/M 

M/M 

See  Note 

6 

message-origin- 

authentication-check 

0 

0/0 

0/0 

message-secur  i  ty-label 

0 

0/0 

0/0 

See  Note 

5 

security-policy-identifier 

0 

M/M 

M/M 

security-classification 

0 

M/M 

M/M 

privacy-mark 

0 

0/0 

0/0 

secur  i  ty-cat egor  i  es 

0 

M/M 

M/M 

content-correlator 

0 

0/0 

0/0 
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Table  34  -  Ciasssfication  of  the  Pi  Protocol  Elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part    3  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

dl-expans ion-history 

0 

0/M 

0/M 

DLExpansionHi story 

internal-t race-information 

0 

M/M 

M/M 

InternalTraceInf o 

per-recipient-f ields 

M 

M/M 

M/M 

recipient-name 

M 

M/M 

M/M 

ORName 

originally-specif ied- 

recipient-number 

M 

M/M 

M/M 

per-recipient-indicators 

M 

M/M 

M/M 

expl i  c  i  t -con ve  r  s  i  on 

0 

0/0 

0/0 

extensions 

0 

0/M 

0/M 

ExtensionField 

originator-requested- 

alternate-recipient 

0 

0/0 

0/0 

requested-del i very-method 

0 

M/M 

0/M 

physical-forwar ding- 

prohibited 

0 

0/0 

0/0 

physical-forwar ding-address- 

request 

0 

0/0 

0/0 

physical-delivery-modes 

0 

0/0 

0/0 

registered-mail-type 

0 

0/0 

0/0 

recipient-number-f or-advice 

0 

0/0 

0/0 

physical-rendition-attributes 

0 

0/0 

0/0 

physical-delivery-report- 

request 

0 

0/0 

0/0 

message-token 

0 

0/0 

0/0 

asymmetric- token 

0 

M/M 

M/M 

See  Note  5 

signature-algorithm- 

identifier 

M 

M/M 

M/M 

name 

M 

M/M 

M/M 

time 

M 

M/M 

M/M 

sign-data 

0 

M/M 

M/M 

content-confidentiality- 

algorithm-identifier 

0 

M/M 

M/M 

content-integrity-check 

0 

M/M 

M/M 

message-security-label 

0 

0/0 

0/0 

proof-of-deli very-request 

0 

M/M 

M/M 

message-sequence-number 

0 

0/0 

0/0 

encrypt  ion-algor  i  thm- 

identif ier 

0 

M/M 

M/M 

encrypted-data 

0 

M/M 

M/M 

content-confidentiality-key 

0 

M/M 

M/M 

content-integrity-check 

0 

M/M 

M/M 

message-security-label 

0 

0/0 

0/0 

content-integrity-key 

0 

0/0 

0/0 

message-sequence-number 

0 

0/0 

0/0 

content-integrity-check 

0 

M/M 

M/M 

See  Note  6 

proof-of-deli very-request 

0 

M/M 

M/M 

See  Note  6 

redirection-history 

0 

0/M 

0/M 
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Table  34  -  Classification  of  the  PI  Protocol  Elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part    4  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments /References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

ProbeTransf erEnvelope 

probe-ident  i  f  ier 

M 

M/M 

M/M 

MTSIdentif ier 

originator-name 

M 

M/M 

M/M 

ORName 

or iginal-encoded-informat ion- 

types 

0 

M/M 

0/0 

EncodedlnformationTypes 

content-type 

M 

M/M 

M/M 

built-in 

0 

M/M 

0/0 

external 

0 

0/M 

0/0 

content-ident i  f ier 

0 

0/M 

0/0 

content-length 

0 

M/M 

0/0 

per-message-indicators 

0 

M/M 

0/M 

disclosure-of -recipients 

0 

0/0 

0/0 

implicit-conversion-prohibited 

0 

M/M 

0/M 

alternate-recipient-allowed 

0 

M/M 

0/0 

content-return-request 

0 

0/0 

0/0 

per-domain-bi lateral- 

information 

0 

0/0 

0/0 

PerDomainBi lateral Info 

trace-information 

M 

M/M 

M/M 

Tracelnformation 

extensions 

0 

M/M 

M/M 

ExtensionField 

recipient-reassignment- 

prohibited 

0 

0/0 

0/0 

dl-expans ion-prohibited 

0 

M/M 

0/M 

conversion-with-loss- 

prohibited 

0 

0/0 

0/0 

or iginator-certi  f icate 

0 

0/0 

0/0 

message— security— label 

o 

o/o 

o/o 

content-correlator 

0 

0/0 

0/0 

probe-origin-authentication- 

check 

0 

0/0 

0/0 

d 1 -expans i on-h i s t or y 

0 

0/M 

0/M 

DLExpans  ionHi  story 

internal-trace- information 

0 

M/M 

M/M 

InternalTracelnfo 

per-recipient-f ields 

M 

M/M 

M/M 

recipient-name 

M 

M/M 

M/M 

ORName 

originally-specif ied- 

recipient-number 

M 

M/M 

M/M 

per-recipient-indicators 

M 

M/M 

M/M 

explicit-conversion 

0 

0/0 

0/0 

extensions 

0 

0/M 

0/M 

ExtensionField 

originator-requested- 

alternate-recipient 

0 

0/0 

0/0 

requested-deli very-method 

0 

M/M 

0/M 

physical-rendition-attributes 

0 

0/0 

0/0 

redirection-history 

0 

0/M 

0/M 
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Table  34  -  Classification  of  the  PI  Protocol  Elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part    5  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

ReportTransf erEnvelope 

report-identifier 

M 

M/M 

M/M 

MTSIdentif ier 

report-destination-name 

M 

M/M 

M/M 

ORName 

trace-information 

M 

M/M 

M/M 

Tracelnformation 

extensions 

0 

M/M 

M/M 

ExtensionField 

message-security-label 

0 

0/0 

0/0 

or  i  g  i  na t  or -and-DL-expans  i  on- 

OriginatorAndDL 

history 

0 

M/M 

0/0 

ExpansionHi story 

r  epo  r  t  i  ng-DL-name 

0 

0/0 

0/0 

report ing-MTA-certificate 

0 

0/0 

0/0 

report-origin-authentication- 

check 

0 

0/0 

0/0 

internal-trace-information 

0 

M/M 

M/M 

InternalTracelnfo 

ReportTransf erContent 

subject-identifier 

M 

M/M 

M/M 

MTSIdentif ier 

sub ject- intermediate-trace- 

information 

0 

M/M 

M/M 

Tracelnformation 

or iginal-encoded-informat ion- 

types 

0 

M/M 

M/M 

EncodedlnformationTypes 

content— type 

U 

iTl/rl 

TW  /tut 

built-in 

0 

M/M 

M/M 

external 

0 

M/M 

M/M 

content-identi  f ier 

0 

M/M 

M/M 

returned-content 

0 

0/M 

0/0 

additional-information 

0 

0/0 

0/0 

extensions 

0 

0/M 

0/M 

ExtensionField 

content-correlator 

0 

0/M 

0/M 

per-recipient-f ields 

M 

M/M 

M/M 

actual-recipient -name 

M 

M/M 

M/M 

ORName 

originally-specif ied- 

recipient-number 

M 

M/M 

M/M 
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Table  34  -  Classification  of  the  Pi  Protocol  Elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part     6  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

per-recipient-indicators 

M 

M/M 

M/M 

last-trace-information 

M 

M/M 

M/M 

arrival-time 

M 

M/M 

M/M 

converted-encoded- 

informat ion-types 

0 

M/M 

M/M 

Encodedinf ormat  ionTypes 

report 

M 

M/M 

M/M 

delivery 

0 

M/M 

0/0 

message-delivery-time 

0 

M/M 

M/M 

t  VDP —of  —MTS — 11  s  p  r 

0 

M/M 

0/0 

All  values  =0/M 

non-delivery 

0 

M/M 

M/M 

non-delivery-reason-code 

0 

M/M 

M/M 

non-delivery-diagnostic- 

code 

0 

0/M 

0/M 

originally-intended-recipient- 

name 

0 

M/M 

M/M 

ORName 

supplementary-information 

0 

0/0 

0/0 

i^n^  "i  one 

o 

M/M 

M/M 

ExtensionField 

redirection-history 

0 

M/M 

M/M 

RedirectionHi story 

physical-forwarding-address 

0 

0/0 

0/0 

recipient-certificate 

0 

0/0 

0/0 

o 

o/o 

o/o 

Common  Data  Types 

Encodedinf ormat  ionTypes 

built-in-encoded-informat ion- 

types 

M 

M/M 

M/M 

See  Note  3 

non-basic-parameters 

0 

0/0 

0/0 

external-encoded-inf ormat ion- 

tvDes 

0 

0/M 

0/M 

MTSIdentif ier 

global-domain-identifier 

M 

M/M 

M/M 

GlobalDomainldentif ier 

local-identifier 

M 

M/M 

M/M 

PerDomainBi lateral Info 

country-name 

M 

M/M 

M/M 

adm  inistrati  on-doma  i  n-name 

0 

M/M 

M/M 

DomainName 

private-domain-identifier 

0 

M/M 

M/M 

DomainName 

(only  encoded  as  SEQ  if 

both  present) 

bilateral-information 

M 

M/M 

M/M 
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Table  34  -  Classification  of  the  PI  Protocol  Elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part     7  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

c 

n/R 

See  Note  1 

Trar'pTn  format"  ^  on 

X  X  uV^^  X  XXI.  v./  X  Xlld      X  vXI  I  1  X  ^lU^XX  c 

M 

M/M 

M/M 

global-domain- identifier 

M 

M/M 

M/M 

GlobalDomainldentif ier 

doma  i  n-suppl i  ed- i  nf orma t  i  on 

M 

M/M 

M/M 

Cki.  I.  XVCIX~CX  iU  V 

M 

M/M 
11  / 11 

M/M 
11  /  11 

rout  inci— act  ion 

M 

M/M 

M/M 

X  c  X  Q  y 

M/M 

11/  11 

M/M 

11/  11 

f  O  fOll  1 
X  VXWU 

n/M 

n/M 

w/  r'l 

54 1 1  omnt  ^^1— rlomj*  i  n 

n 

n/M 
11 

n/M 

w/  11 

GlobalDomainldent  i  f  i  er 

Hpf^^rrp^l— t  "i  mp 

U  ^  X  ^  X  X  ^  U       if  X  lUC 

n 

M/M 

1 1/  11 

M/M 

11/  1 1 

converted-encoded- 

informat ion-types 

0 

0/M 

0/M 

EncodedlnformationTypes 

other —act  ions 

0 

0/M 

0/M 

redi  rected 

0 

0/M 

0/M 

dl— otierat  ion 

0 

0/M 

0/M 

ExtensionField 

type 

M 

M/M 

M/M 

<^T1  "t"!  *^J4l  1  +"\7 
V.rX  X  ^X^CIXX  Ujr 

n  /M 

W  /  11 

n/M 

f  o  T" — Q 1 1  Htn  1  c*  ci  ■!  on 

j_          ~s  UWIUX  S3  O  X  v/11 

n 

n/n 

n/n 

for  — t  ran^fpr 

XVh/X  I^XuXXOX^X 

o 

M/M 

M/M 

for— dpi i vpr V 

0 

M/M 

M/M 

value 

M 

M/M 

M/M 

DLExpansionHi  story 

DLExpans  i  on 

M 

M/M 

M/M 

ORAddressAndOpt  ionalDi  rectory 

Name 

M 

M/M 

M/M 

ORName 

dl— expansion— t  ime 

M 

M/M 

M/M 

Int p rna  1  Trar'pTn f  orina  i"  i  on 

XXX^^X.XXC&X.X  XCXVi^^XXXX.  \J  L,  Xllu  Kf  X  \_/XXXJ  X  CSXllCXX  u 

M 

X  i 

M/M 
1 1/ 11 

M  /M 
1 1/ 1 1 

alobal  — dotna  in— idpirfi  f  i  e^r 

X\.yia^CX  X      UWXllCi  X  XX      X  U^XX  ^  X  X.  X  C  X 

M 

M/M 

1  1/  1 1 

M/M 

1 1/  1  1 

GlobalDomainldentif ier 

mta-name 

M 

M/M 

M/M 

mta-supplied- information 

M 

M/M 

M/M 

ar  r  i  va  1  —  t  "i  mp 

WX  XXAVmX       ifX  xu^ 

M 

M/M 

1  1/  1 1 

M/M 

1 1/  1  1 

Ton  t  "i  nn  r^t  i  on 

X           L>  XlXt^~Cl^  L>  X  wll 

M 

M  /M 

Fx 

M/M 

11/  n 

relayed 

0 

M/M 

M/M 

rerouted 

0 

0/M 

0/M 

attempted 

0 

mta 

0 

0/M 

0/M 

domain 

0 

0/M 

0/M 

GlobalDomainldentif ier 

deferred-time 

0 

0/M 

0/M 

other-actions 

0 

0/M 

0/M 

redirected 

0 

0/M 

0/M 

dl-operation 

0 

0/M 

0/M 

Or iginatorAndDLExpansionHi story 

originator-or-dl-name 

M 

M/M 

M/M 

or igination-or-expans ion-time 

M 

M/M 

M/M 
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Table  34  -  Classification  of  the  PI  Protocol  Elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part     8  of  9 

MT  Kernel  Support  by  MTS  Class 

Comment  s/Re  f  e  r  ences 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

RedirectionHistory 

Redirection 

M 

M/M 

M/M 

intended-recipient-name 

M 

M/M 

M/M 

ORAddressAndOpt  ionalDi  rectory 

Name 

M 

M/M 

M/M 

ORName 

redi  rect  ion-t  ime 

M 

M/M 

M/M 

redirection-reason 

M 

M/M 

M/M 

ORName 

address 

M 

M/M 

M/M 

standard-attributes 

M 

M/M 

M/M 

country-name 

0 

M/M 

0/M 

Count ryName 

administration-domain-name 

0 

M/M 

0/M 

DomainName 

network-address 

0 

M/M 

0/M 

terminal-identifier 

0 

M/M 

0/M 

pr  i  va t e-doma  i  n-name 

0 

M/M 

0/M 

DomainName 

organi  zat  ion-name 

0 

M/M 

0/M 

numeric-user-identifier 

0 

M/M 

0/M 

personal-name 

0 

M/M 

0/M 

surname 

M 

M/M 

M/M 

given-name 

0 

M/M 

0/M 

initials 

0 

M/M 

0/M 

See  Note  4 

generation-qualifier 

0 

M/M 

0/M 

or gani  zat  ional-uni  t-names 

0 

M/M 

0/M 

Organi  zat  ionUni  tName 

M 

M/M 

0/M 

domain-defined-at tributes 

0 

M/M 

0/M 

DomainDefinedAt tribute 

M 

M/M 

0/M 

type 

M 

M/M 

M/M 

value 

M 

M/M 

M/M 

extension-attributes 

0 

0/M 

0/M 

Ext ens ionAt tribute 

common-name 

0 

0/M 

0/M 

n/M 

n/M 

teletex-organi zat ion-name 

0 

M/M 

0/M 

t  e 1 e  t  ex-pe  r  s  ona 1 -name 

0 

M/M 

0/M 

teletex-organi zat ional-uni t- 

names 

0 

M/M 

0/M 

teletex-domain-def ined- 

attributes 

0 

M/M 

0/M 

pds-name 

0 

0/M 

0/M 

physical-delivery-country- 

name 

0 

0/M 

0/M 

postal-code 

0 

0/M 

0/M 

phys  i  cal -de live  r y-of  f  i  ce-name 

0 

0/M 

0/M 
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December  1990  (Stable) 


Table  34  -  Classification  of  the  PI  Protocol  Elements  (concluded) 


MTS  Transfer  Protocol  (PI) 


Part     9  of  9 


MT  Kernel  Support  by  MTS  Class 


Protocol  Element 


B/C 
0/R 


A 

0/R 


Comments/References 


See  Note  1 


physical-delivery-office- 
number 

extension-OR-address- 
components 

physical-delivery-personal- 
name 

physical-delivery- 

organizati  on-name 

extens  ion-phys  i  cal-del i very- 
address -components 

unformatted-postal-address 

street-address 

post-office-box-address 

poste-rest ante-address 

un  i  que-pos  t  a 1 -name 

local-postal-attributes 

extended-network-address 

terminal-type 
directory-name 

Extens ionAt tribute 
extension-attribute-type 
extension-attribute-value 

GlobalDomainldentif ier 
country-name 

administrati  on-doma  i  n-name 
private-domain-identifier 

Count ryName 
xl21-dcc-code 
iso-3166-alpha2-code 

DomainName 
numeric 
printable 


0/M 

0/M 

0/M 

0/M 

0/M 
0/M 
0/M 
0/M 
0/M 
0/M 
0/M 
0/M 
0/M 
0/0 


M/M 
M/M 


M/M 
M/M 
M/M 


0/M 
M/M 


0/M 
M/M 


0/M 

0/M 

0/M 

0/M 

0/M 
0/M 
0/M 
0/M 
0/M 
0/M 
0/M 
0/M 
0/M 
0/0 


M/M 
M/M 


M/M 
M/M 
0/M 


0/M 
0/M 


0/M 
0/M 


Count  ryName 

DomainName 

DomainName 


Notes  ( cont  i nued ) 

3  An  implementation  is  only  required  to  generate  EITs  that 
correspond  to  the  body  parts  it  is  capable  of  generating. 

4  If  the  initials  component  of  personal-name  attribute  is  used, 
it  should  comprise  all  of  the  person's  initials  (including  the 
given  name)  except  the  person's  surname,  as  specified  in 
X.402/IS  10021-2. 

5  All  SO  services  may  be  provided  without  using  the  message  token, 

e.g.,  using  per-message  extensions. 
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A.2      Interpersonal  Messaging  Protocol  (P2) 


Table  35  -  Classification  of  the  P2  Protocol  Elements 


Interpersonal  Messaging  Protocol 

(P2) 

Part  1  of  3 

Support 

by 

UA 

Protocol  Element 

s 

0/R 

Comments/References 

InformationOb ject 

ipm 

0 

M/M 

IPM 

ipn 

0 

M/M 

IPN  -  see  Note  4 

IPM 

heading 

M 

M/M 

this-IPM 

M 

M/M 

IPMIdentif ier 

originator 

0 

M/M 

ORDescriptor 

author i zing-users 

0 

0/M 

Rec  i  pi  ent  Spec  i  f  i  e  r 

primary-recipients 

0 

TUT  /TUT 
M/M 

RecipientSpecif ier 

copy-recipients 

0 

M/M 

Rec  i  pi  ent Spec  i  f  i  er 

blind-copy-recipients 

0 

0/M 

RecipientSpecif ier 

replied-to-IPM 

0 

M/M 

IPMIdentif ier 

obsoleted-IPMs 

0 

0/M 

IPMIdentif ier 

related-IPMs 

0 

O/M 

IPMIdentif ier 

subject 

0 

Tuf  /xjr 

See  Note  1, 

8 

expiry-time 

0 

r\  /\M 

U/M 

reply-time 

0 

U/M 

reply-recipients 

0 

U/M 

ORDescriptor 

importance 

0 

O/M 

sensitivity 

0 

O/M 

auto-forwarded 

0 

O/M 

extensions 

0 

O/M 

HeadingExtension 

incomplete-copy 

0 

o/o 

languages 

0 

U/M 

bodv 

M 

M/M 

Body Part 

IPN 

common- f i e 1 d s 

M 

M/M 

sub ject-ipm 

M 

M/M 

ipn-originator 

0 

M/M 

ORDescriptor 

ipm-prefer red-recipient 

0 

M/M 

ORDescriptor 

conve  r  s  i  on-e  its 

0 

0/M 

EncodedInf ormationTypes 

non-receipt-fields 

0 

M/M 

See  Note  5 

non-receipt-reason 

M 

M/M 

discard-reason 

0 

M/M 

auto-forward-comment 

0 

0/M 

returned-ipm 

0 

0/0 

See  Note  2 

receipt-fields 

0 

0/M 

receipt-time 

M 

M/M 
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Table  35  -  Classification  of  the  P2  Protocol  Elements  (continued) 


Interpersonal  Messaging  Protocol 

(P2) 

Part  2  of  3 

Support 

by 

UA 

Protocol  Element 

S 

0/R 

Comments/References 

acknowledgment -mode 

0 

0/M 

suppl-receipt-inf o 

0 

0/0 

Head  i  ngEx  t  ens  i  on 

type 

M 

M/M 

value 

M 

M/M 

IPMIdentif ier 

user 

0 

0/M 

user-relative-identifier 

M 

M/M 

ORDescriptor 

formal-name 

0 

0/M 

ORName  -  see  Note  3 

free-form-name 

0 

0/M 

See  Note  8 

t  e 1 ephone -numbe  r 

0 

0/M 

RecipientSpecif ier 

recipient 

M 

M/M 

ORDescriptor 

notification-requests 

0 

0/M 

reply-requested 

0 

0/M 

BodyPart 

ia5-text 

0 

M/M 

parameters 

M 

M/M 

repertoire 

0 

0/M 

See  Note  6 

data 

M 

M/M 

voice 

0 

* 

See  Note  7 

g3-f acsimile 

0 

0/0 

parameters 

M 

M/M 

number-of -pages 

0 

0/M 

non-basic-parameters 

0 

0/M 

data 

M 

M/M 

g4-classl 

0 

0/0 

teletex 

0 

0/0 

parameters 

M 

n./  f*i 

number-of -pages 

0 

0/0 

telex-compatible 

0 

0/0 

non-bas  i  c-pa  r  ame t  e  r  s 

0 

0/0 

data 

M 

M/M 

videotex 

0 

0/0 

parameters 

M 

M/M 

syntax 

0 

0/M 

data 

M 

M/M 

encrypted 

0 

* 

See  Note  7 
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December  1990  (Stable) 


Table  35  -  Classification  of  the  P2  Protocol  Elements  (coricluded) 


Interpersonal  Messaging  Protocol  (P2) 


Part  3  of  3 


Protocol  Element 


Support  by 
UA 
0/R 


Conraients/Ref  erences 


message 
pareuneters 
delivery-time 
delivery-envelope 

data 
mixed-mode 
bilaterally-defined 
nationally-defined 
externally-defined 

parameters 

data 

GeneralTextBodyPart 


0/M 
M/M 
0/M 
0/M 

M/M 
0/0 

0/0 
0/0 
0/M 
M/M 
M/M 


See  P3  OtherMessage 
Del iveryFi elds 


Notes 

1  The  ability  to  generate  the  maximum  size  subject  is  not 
required. 

2  May  only  be  included  if  specifically  requested  by  the 
originator . 

3  The  ORName  should  be  specified  wherever  possible. 

4  The  ability  to  generate  an  IPN  is  optional  in  the  case  of 
an  implementation  in  which  a  non-receipt  condition  cannot 
occur  and  receipt  notification  is  not  supported  (see 
table  5). 

5  The  ability  to  generate  non-receipt-fields  is  optional  in 
the  case  of  an  implementation  in  which  a  non-receipt 
condition  cannot  occur  (see  note  4). 

6  Only  the  IA5  repertoire  has  to  be  supported  for  an 
ia5-text  body  part  on  reception. 

7  The  definition  of  these  body  parts  is  for  further  study  in 
CCITT  and  ISO. 

8  Only  the  IA5  subset  of  the  T.61  character  repertoire  need 
be  generated.  All  T.61  characters  should  be  supported  on 
reception. 
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Part  8:  1988  Message  Handling  Systems 


December  1990  (Stable) 


A.3      MTS  Access  Protocol  (P3) 

NOTE  -  The  support  classifications  for  the  IPM  UA,  MS  and  MTA  below  indicate  the  minimum  level  of  support 
required  by  implementations  conforming  to  these  Agreements,  and  should  not  be  misconstrued  as  a 
redefinition  of  any  of  the  MHS  application  contexts. 


Table  36  -  Classification  of  the  P3  Protocol  Elements 


MTS  Access  Protocol  (P3) 

Part    1  of  12 

Support 

by: 

IPM 

UA 

0/R 

MS 
0/R 

MTA 
0/R 

Protocol  Element 

S 

Comments/References 

Operations 

MTSBind 
MTSUnbind 

M 
M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 

MTSBind 

MSSE 

message-submission 
probe-submission 
cancel-deferred-delivery 
submi  s  s  i  on-cont  r ol 

M 
M 
M 
M 

M/- 
0/- 
0/- 
-/M 

M/M 
M/M 
M/M 
M/M 

-/M 
-/M 
-/M 
0/- 

MessageSubmission 
ProbeSubmission 
CancelDef erredDelivery 
Submi  s  s  ionCont  rol 

MDSE 

message-delivery 

report-delivery 

delivery-control 

M 
M 
M 

-/M 
-/M 
0/- 

M/M 
M/M 
0/- 

M/- 
M/- 
-/M 

MessageDelivery 

ReportDelivery 

DeliveryControl 

MASE 
register 

change-credentials 

(MTS  to  MTSuser) 
(MTSuser  to  MTS) 

M 

M 
M 

0/- 

-/M 
0/- 

M/M 

M/M 
M/M 

-/M 

0/- 
-/M 

Register 

ChangeCr edent  i  als 
ChangeCredentials 

Note  -    A  Message  Store  must 
operations  unaltered. 

pass  through  all  MSSE  and  MASE 
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Table  36  -  Classification  of  the  P3  Protocol  Elements  (continued) 


MTS  Access  Protocol  (P3) 

Part     2  of  12 

Support  by: 

T  TiUt 

Urn. 

urc* 

UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments /References 

Arguments/Results 

MTSBind 

MTS  to  MTS  User 

ARGUMENT 

ini  t  i  ator-neune 

M 

-/M 

-/M 

M/- 

MTS-user 

/- 

-/ 

/ 

MTA 

0 

/M 

M/ 
M/- 

isMessageStore 

/ 

/ 

/ 

mes  sages -wa  i  t  i  ng 

0 

-/O 

-/O 

0/- 

initiator-credentials 

M 

-/M 

/TUT 
-/M 

M/- 

simple 

0 

-/M 

-/M 

M/- 

strong 

0 

-/o 

-/o 

0/- 

secur  i  ty-context 

0 

-/o 

~/o 

0/- 

1-256 

RESULT 

responder-name 

M 

M/- 

M/- 

-/M 

MTS-user 

0 

M/- 

M/- 

-/M 

MTA 

/ 

/- 

ismessagestore 

0 

n/  — 

M/_ 
ra/- 

-  /M 

messages-waiting 

/ 

/ 

/ 

responder-credentials 

M 

M/- 

M/- 

-/M 

simple 

0 

M/- 

-/M 

strong 

0 

u/- 

-/u 

MTSBind 

MTS  User  to  MTS 

ARGUMENT 

initiator-name 

M 

M/- 

M/- 

-/M 

mTS-user 

0 

M/- 

M  / 

/M 

mTA 

-/- 

/ 

isMessageStore 

0 

n/- 

messages-waiting 

/ 

initiator-credentials 

M 

M/_ 

n/  — 

M/_ 

n/- 

-/M 

s impxs 

r\ 
U 

M/- 

M/- 

-/M 

strong 

0 

0/- 

0/- 

-/o 

security-context 

0 

0/- 

0/- 

-/o 

1-256 

RESULT 

responder-name 

M 

-/M 

-/M 

M/- 

mTS-user 

-/- 

-/- 

-/- 

mTA 

0 

-/M 

-/M 

M/- 

isMessageStore 

-/- 

-/- 

-/- 

mes sages -waiting 

0 

-/o 

-/o 

0/- 

responder-credentials 

M 

-/M 

-/M 

M/- 

simple 

0 

-/M 

-/M 

M/- 

strong 

0 

-/o 

-/o 

0/- 
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Table  36  -  Classification  of  the  P3  Protocol  Elements  (continued) 


MTS  Access  Protocol  (P3) 

Part     3  of  12 

Support  by: 

IPM 

UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comment  s /References 

Me  s  s  ageSubmi  s  s  i  on 

ARGUMENT 

envelope 

M 

M/- 

M/- 

-/M 

MessageSubmi ssion 

Envelope 

content 

M 

M/- 

M/- 

-/M 

RESULT 

mes s age-submi s s i on- i dent i £ i er 

M 

-/M 

-/M 

M/- 

See  PI  MTSIdentif ier 

message-submi  ss  ion-t  ime 

M 

-/M 

-/M 

M/- 

content-identifier 

0 

-/M 

-/M 

M/- 

extensions 

0 

-/o 

-/o 

0/- 

or iginat ing-MTA-cert if icate 

0 

-/O 

-/O 

n  / 
O/- 

proof -of -submi  ssion 

0 

-/o 

-/o 

0/- 

P r obeSubmi  s s  i on 

ARGUMENT 

envelope 

M 

M/- 

M/- 

-/M 

ProbeSubmi ssion 

Envelope 

prooe— suuini  ss  ion— i  aenr  i  r  i  sr 

Tur 

n 

-/M 

-/M 

M/- 

See  PI  MTSIdentif ier 

probe-submiss ion-time 

M 

-/M 

-/M 

M/- 

content— 1 aent i e i er 

U 

-/M 

-/M 

M/- 

CancelDef err edDeli very 

ARGUMENT 

message— submission— identi  f ier 

M 

M/- 

M/- 

-/M 

See  PI  MTSIdentif ier 

Submi s  s 1 onCont  r ol 

IV  D r  Turc  KT  m 
AKGUMTiNT 

controls 

M 

-/M 

-/M 

M/- 

See  Note  1 

restrict 

0 

-/M 

-/M 

0/- 

permissible-operations 

0 

-/M 

-/M 

0/- 

permissible-maximum-content- 

length 

0 

-/M 

-/M 

0/- 

permissible-lowest-priority 

0 

-/M 
—/II 

-/M 

0/- 

permi  ss  ible-secur  i  ty-context 

0 

-/o 

-/o 

0/- 

RESULT 

waiting 

M 

M/- 

M/- 

-/M 

See  Note  2 

wa  i  t  i  ng-ope  r  a t  i  ons 

0 

0/- 

0/- 

-/M 

0-16 

waiting-messages 

0 

0/- 

0/- 

-/M 

waiting-content-types 

0 

0/- 

0/- 

-/M 

0-1024 

waiting-encoded-informat ion- 

See  PI  Encoded 

types 

0 

0/- 

0/- 

-/M 

InformationTypes 
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Table  36  -  Classification  of  the  P3  Protocol  Elements  (continued) 


MTS  Access  Protocol  (P3) 

Part    4  of  12 

Support  by: 

IPM 

UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments/References 

MessageDel i very 

ARGUMENT 

M 

-/M 

-/M 

M/- 

MessageDeliver  y En ve 1 ope 

content 

M 

-/M 

-/M 

M/- 

RESULT 

reciTDient— cert  i  f  icate 

0 

0/- 

0/- 

-/o 

proof —of —deli very 

0 

0/- 

0/- 

-/o 

ReportDe livery 

ARGUMENT 

envelope 

M 

-/M 

-/M 

M/- 

ReportDeliveryEnvelope 

returned— content 

0 

-/M 

-/M 

0/- 

Deli veryCont rol 

ARGUMENT 

controls 

M 

M/- 

M/- 

-/M 

See  Note  3 

restrict 

0 

0/- 

0/- 

-/M 

Dermi ss ible— onerat i ons 

0 

0/- 

0/- 

-/M 

permissible-maximum-content- 

length 

0 

0/- 

0/- 

-/M 

permiss  ible— lowest— prior ity 

0 

0/- 

0/- 

-/M 

permiss  ible— content— types 

0 

0/- 

0/- 

-/M 

permiss  ible— encoded— 

See  PI  Encoded 

inf ormat  ion— types 

0 

0/- 

0/- 

-/M 

InformationTypes 

permi  ss  ible— secur  i  ty— context 

0 

0/- 

0/- 

-/O 

RESULT 

wa  i  t  i  ng 

M 

-/M 

-/M 

M/- 

See  Note  4 

wa  i  t  i  ng —ope  rati  ons 

0 

-/M 

-/M 

0/- 

wai  ting— messages 

0 

-/M 

-/M 

0/- 

wai  t  ing-content-types 

0 

-/M 

-/M 

0/- 

waiting-encoded-informat ion- 

See  PI  Encoded 

types 

0 

-/M 

-/M 

0/- 

Informati  onTy pe  s 

Register 

See  Note  5 

ARGUMENT 

user -name 

0 

0/- 

0/- 

-/o 

See  X.411 

,  8.4.1.1.1.1 

user-address 

0 

0/- 

0/- 

-/o 

deliverable-encoded- 

See  PI  Encoded 

informat ion-types 

0 

0/- 

M/- 

-/M 

Inf ormat  ionTypes 

deliverable-maximum-content- 

length 

0 

0/- 

M/- 

-/M 

default-delivery-controls 

0 

0/- 

0/- 

-/M 

restrict 

0 

0/- 

0/- 

-/M 
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Table  36  -  Classification  of  the  P3  Protocol  Elements  (continued) 


MTS  Access  Protocol  (P3) 

Part    5  of  12 

Support  by: 

IPM 

UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments /References 

permissible-operations 

0 

0/- 

0/- 

-/M 

permissible-maximiim-content- 

length 

0 

0/- 

0/- 

-/M 

permissible-lowest-priority 

0 

0/- 

0/- 

-/M 

permi  ss  i  ble— content —types 

0 

0/- 

0/- 

-/M 

1-1024 

permi ss ible— encoded— 

See  PI  Encoded 

information-types 

0 

0/- 

0/- 

-/M 

InformationTypes 

deli verable— content— types 

o 

0/- 

M/- 

-/M 

1-1024 

labels-and-redi  rect  ions 

0 

0/- 

0/- 

-/o 

1-256 

user-security-label 

0 

0/- 

0/- 

-/o 

recipient-assigned-alternate- 

recipient 

0 

0/- 

0/- 

-/o 

ChangeCredent lals 

MTS  to  MTSuser 

ARGUMENT 

old-credentials 

M 

-/M 

-/M 

M/- 

Note  8 

simple 

0 

-/M 

-/M 

0/- 

strong 

0 

-/o 

-/o 

0/- 

new-credentials 

M 

-/M 

-/M 

M/- 

Note  8 

simple 

0 

-/M 

-/M 

0/- 

strong 

0 

-/o 

-/o 

0/- 

ChangeCredent ials 

MTSuser  to  MTS 

A  T3 T  TTurc^xim 
AKCjUMJiNT 

old— credentials 

M 

M/- 

M/- 

-/M 

Note  8 

s  imple 

U 

0/- 

0/- 

-/M 

strong 

u 

0/- 

0/- 

-/o 

new-credentials 

M 

M/- 

M/- 

-/M 

Note  8 

simple 

O 

0/- 

0/- 

-/M 

strong 

0 

0/- 

0/- 

-/o 

Me  s  s  ageSubmi  s  s  i  onEnve 1 ope 

See  Note  6 

originator-name 

M 

M/- 

M/- 

-/M 

See  ORName 

or iginal-encoded-informat ion- 

See  PI  Encoded 

types 

0 

M/- 

M/- 

-/M 

Inf ormat  ionTypes 

content-type 

M 

M/- 

M/- 

-/M 

built-in 

0 

0/- 

M/- 

-/M 

external 

0 

0/- 

M/- 

-/M 

content-identifier 

0 

0/- 

M/- 

-/M 

1-16 

priority 

0 

M/- 

M/- 

-/M 

All  values 

per-message-indicators 

0 

M/- 

M/- 

-/M 

disclosure-of -recipients 

0 

0/- 

M/- 

-/M 
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Table  36  -  Classification  of  the  P3  Protocol  Elements  (continued) 


MTS  Access  Protocol  (P3) 

Part     6  of  12 

Support  by: 

IPM 
UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comment  s /Re  f  e  r ences 

i  mpl i  c  i  t -conve  r  s  i  on-pr oh  i  b  i  t  ed 

0 

M/- 

M/- 

-/M 

alternate-recipient-allowed 

0 

M/- 

M/- 

-/M 

content-return-request 

0 

0/- 

M/- 

-/H 

deferred-delivery-time 

0 

M/- 

M/- 

-/M 

extensions 

0 

M/- 

M/- 

-/M 

recipient-reassignment- 

prohibited 

0 

0/- 

M/- 

-/M 

d 1 -expans  i  on-pr oh  i  b  i  t  ed 

0 

M/- 

M/- 

-/M 

conversion-wi th-loss- 

prohibited 

0 

0/- 

M/- 

-/M 

latest-deli very- time 

0 

0/- 

M/- 

-/M 

originator-return-address 

0 

0/- 

M/- 

-/M 

originator-certificate 

0 

0/- 

0/- 

-/o 

cont ent-conf  i  dent  i  al i  ty- 

algor  i  thm- i  dent  i  f  i  er 

0 

0/- 

0/- 

-/o 

message-origin- 

au t hent  i  ca t  i  on-check 

0 

0/- 

0/- 

-/o 

message-secur  i  ty-label 

0 

0/- 

0/- 

-/o 

proof-of-submiss ion-request 

0 

0/- 

0/- 

-/o 

content-correlator 

0 

0/- 

M/- 

-/M 

forwarding-request 

0 

0/- 

0/- 

-/M 

MS  Abstract  Service  only 

PerRecipientMessageSubmission 

Fields 

M 

M/- 

M/- 

-/M 

1-32767 

recipient-name 

M 

M/- 

M/- 

-/M 

See  ORNeune 

originator-report-request 

M 

M/- 

M/- 

-/M 

expl i  c  i  t -conve  r  s  i  on 

0 

0/- 

M/- 

-/M 

extensions 

0 

M/- 

M/- 

-/M 

originator-requested- 

alternate-recipient 

0 

0/- 

0/- 

-/O 

£6(^Ut?D^t?Cl— X  VTSLy- ilt€UliV^Q 

M/- 

M/- 

-/M 

Note  9 

phys  ical-f orwarding- 

prohibited 

0 

O/- 

M/- 

/yi 

phys ical-f orwarding-address- 

request 

0 

0/- 

0/- 

-/o 

physical-delivery-modes 

0 

0/- 

0/- 

-/o 

registered-mail-type 

0 

0/- 

0/- 

-/o 

recipient-number-for-advice 

0 

0/- 

0/- 

-/o 

physical-rendition-attributes 

0 

0/- 

0/- 

-/o 

physical-delivery-report- 

request 

0 

0/- 

0/- 

-/o 

message-token 

0 

0/- 

0/- 

-/o 

content-integr  i  ty-check 

0 

0/- 

0/- 

-/o 

proof -of -deli very-request 

0 

0/- 

0/- 

-/o 
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Table  36  -  Classification  of  the  P3  Protocol  Elements  (continued) 


MTS  Access  Protocol  (P3) 

Part     7  of  12 

Support  by: 

TDM 
J.  trn 

TTa 

MTA 

FIX  r\ 

Protocol  Element 

S 

U/  K 

Comments/Ref erences 

ProbeSubnti  ss  ionEnvelope 

See  Note  6 

originator-name 

M 

M/ 

n/- 

Pl/- 

-/PI 

See  ORName 

or iginal-encoded-informat ion- 

See  PI  Encoded 

types 

0 

M/- 
n/  — 

M/- 

-/M 

InformationTypes 

content-type 

M 

M/- 

/M 
-/M 

built-in 

0 

O/- 

M/- 

-/M 
— /n 

0-32767 

external 

0 

n/_ 
u/ - 

n/  — 

_/M 
-/n 

content-identifier 

0 

O/- 

u/  — 

M/- 
n/- 

-/M 
—/PI 

1-16 

content-length 

0 

M/- 
n/- 

M/- 
pi/  — 

-/M 
—/PI 

1-'7FFFFFFF'H 

per-message-indicators 

0 

n/- 

/M 
-/PI 

implicit-conversion-prohibited 

0 

M/- 
n/  — 

M/- 

-/M 
— /  Pi 

alternate-recipient-allowed 

0 

u/- 

n/- 

/M 
-/PI 

extensions 

0 

M/- 

M/- 

-/M 
—/PI 

recipient-reassignment- 

prohibited 

0 

O/- 

M/- 

-/M 
—/PI 

dl-expans  ion-prohibi  ted 

0 

n/- 

n/- 

/M 

-/n 

conversion-with-loss- 

prohibited 

0 

u/- 

M/ 

n/- 

/M 
-/M 

originator-certificate 

0 

u/- 

n  / 
u/- 

/n 
-/u 

message-security-label 

0 

u/- 

/n 
-/u 

content-correlator 

0 

0/- 

M/- 

-/M 

probe-origin-authentication- 

check 

0 

VJ/- 

-/u 

PerRecipientProbeSubmission 

Fields 

M 

n/- 

n/- 

_  /M 

-/n 

1-32767 

recipient-name 

M 

pi/- 

n/  - 

_  /M 

-/PI 

See  ORName 

originator-report-request 

M 

M/- 

M/- 

pi/  — 

-/M 
—/PI 

exp 1 i  c  i  t -conve  r  s  i  on 

0 

n/- 

M/- 

-/M 
—/PI 

0-256 

extensions 

0 

M/- 

M/- 

-/M 
—/II 

alternate-recipient 

0 

0/- 

0/- 

-/o 

requested-deli very-method 

0 

M/- 

M/- 

-/M 

0-256,  Note  9 

physical-rendition-attributes 

0 

0/- 

M/- 

-/M 

MessageDeliveryEnvelope 

See  Note  7 

message-delivery-identifier 

M 

-/M 

-/M 

M/- 

See  PI  MTSIdentif ier 

message-delivery-time 

M 

-/M 

-/M 

M/- 

other-fields 

M 

-/M 

-/M 

M/- 

content-type 

M 

-/M 

-/M 

M/- 

built-in 

0 

-/M 

-/M 

M/- 

0-32767 

external 

0 

-/M 

-/M 

M/- 

originator-name 

M 

-/M 

-/M 

M/- 

See  ORName 
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Table  36  -  Classification  of  the  P3  Protocol  Elements  (continued) 


MTS  Access  Protocol  (P3) 

Part     8  of  12 

Support  by: 

IPM 

UA 

MS 

MTA 

Protocol  Element 

S 

O/R 

O/R 

O/R 

Comment s/Ref erences 

— 

original-encoded-informat ion- 

See  PI  Encoded 

types 

0 

-/M 

-/M 

M/- 

Inf ormationTypes 

priority 

o 

-/M 

-/M 

M/- 

All  values 

delivery- flags 

0 

-/M 

-/M 

M/- 

implicit— conversion- 

prohibited 

O 

-/M 

-/M 

M/- 

other-recipient-names 

0 

-/M 

-/M 

M/- 

See  ORName 

this— recipient— name 

M 

-/M 

-/M 

M/- 

See  ORName 

originally— intended— recipient — 

name 

O 

-/M 

-/M 

M/- 

See  ORName 

converted-encoded- in format ion- 

See  PI  Encoded 

types 

0 

-/M 

-/M 

M/- 

Inf ormationTypes 

message— submission— time 

J,  / 
M 

-/M 

-/M 

M/- 

content-ident if ier 

0 

-/M 

-/M 

M/- 

1-16 

extensions 

o 

-/M 

-/M 

M/- 

convers ion-wit h- loss- 

prohibited 

0 

-/M 

-/M 

M/- 

requested-de livery-met hod 

o 

-/M 

-/M 

M/- 

Note  9 

physical— forwarding— 

pron  j.^6Q 

r\ 
\J 

-/I 

M/- 

pnysxcax   lorwarci j.ny  aciciress 

request 

U 

-/i 

-/- 

M/- 

physical— del i very— modes 

r\ 
U 

-/i 

-/- 

M/- 

0-16 

registered— mail— type 

U 

-/i 

-/- 

M/- 

0-256 

recipient— number— for— advice 

f-\ 

o 

-/i 

M/- 

1-32 

physical-rendition-attributes 

0 

-/:| 

-/- 

M/- 

physical-delivery-report- 

request 

o 

-/i 

M/- 

0-256 

originator-return-address 

o 

-/i 

-/- 

M/- 

originator-certificate 

o 

-/O 

0/- 

message- token 

0 

-/o 

-/o 

o/- 

content-confidentiality- 

algorithm-  identifier 

0 

-/o 

-/o 

0/- 

content- integrity-check 

0 

-/o 

-/o 

0/- 

message-origin- 

authentication-check 

0 

-/o 

-/o 

0/- 

message-security- label 

o 

-/o 

-/o 

o/- 

proof -of -de livery-request 

0 

-/o 

-/o 

0/- 

redirection-history 

o 

-/M 

-/M 

M/- 

1-512 

dl-expans ion-history 

0 

-/M 

-/M 

M/- 

1-512 
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Table  36  -  Classification  of  the  P3  Protocol  Elements  (continued) 


MTS  Access  Protocol  (P3) 

Part    9  of  12 

Support  by: 

IPM 

UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments/References 

ReportDeliveryEnvelope 

See  Note  7 

sub ject-submiss ion-identifier 

M 

-/M 

-/M 

M/- 

See  PI  MTSIdentif ier 

content-identifier 

0 

-/M 

-/M 

M/- 

content-type 

0 

-/M 

-/M 

M/- 

built-in 

0 

-/M 

-/M 

M/- 

0-32767 

external 

0 

-/M 

-/M 

M/- 

or  i  g  i  nal -encoded- i  nf orma t  i  on- 

See  PI  Encoded 

type  s 

0 

-/M 

-/M 

M/- 

Informati  onType  s 

extensions 

0 

-/M 

-/M 

M/- 

message-secur  i  ty-label 

0 

-/o 

-/O 

0/- 

content-correlator 

0 

-/M 

-/M 

M/- 

or iginator-and-DL-expans ion- 

See  PI  OriginatorAndDL 

history 

0 

-/M 

-/M 

M/- 

Expans  i  onH  i  s  t  or y 

reporting-DL-name 

0 

-/M 

-/M 

M/- 

report ing-MTA-cert if icate 

0 

-/O 

-/O 

0/- 

r  epor  t -or  i  g  i  n-aut hent  i  ca t  i  on- 

check 

0 

-/o 

-/O 

0/- 

PerReci pi entReportDeli very- 

Fields 

M 

-/M 

-/M 

M/- 

1-32767 

actual-recipient-neune 

M 

-/M 

-/M 

M/- 

See  ORName 

report 

M 

-/M 

-/M 

M/- 

delivery 

0 

-/M 

-/M 

M/- 

message-delivery-time 

M 

-/M 

-/M 

M/- 

type-of-MTS-user 

0 

-/M 

-/M 

M/- 

non-delivery 

0 

-/M 

-/M 

M/- 

non-delivery-reason-code 

M 

-/M 

-/M 

M/- 

non-delivery-diagnostic-code 

0 

/xs 

-/M 

-/M 

M/- 

converted-encoded-informat ion- 

See  PI  Encoded 

types 

0 

-/M 

-/M 

M/- 

Informati onTypes 

originally-intended-recipient- 

name 

0 

-/M 

-/M 

M/- 

See  ORName 

supplementary-information 

0 

-/M 

-/M 

M/- 

1-256 

extensions 

0 

-/M 

-/M 

M/- 

redirection-history 

0 

— /n 

— /M 

M/- 

See  PI  Redirection 

History,  1-512 

physical-f orwarding-address 

0 

-/M 

-/M 

M/- 

recipient-certificate 

0 

-/o 

-/o 

0/- 

proof -of -deli very 

0 

-/o 

-/o 

0/- 

ORName 

MTS  User  to  MTS 

standard-attributes 

country-name 

0 

M/- 

M/- 

-/ 

Count ryName 

administration-domain-name 

0 

M/- 

M/- 

-/M 

DomainName 

network-address 

0 

0/- 

0/- 

-/M 

terminal-identifier 

0 

0/- 

0/- 

-/M 
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Table  36  -  Classification  of  the  P3  Protocol  Elements  (continued) 


MTS  Access  Protocol  (P3) 

Part  10  of  12 

Support  by: 

TDM 

FTA 

MC 

\it\ 

no 

Protocol  Element 

S 

Ki/  K 

<J/  K 

private-domain-name 

0 

M/- 

M/_ 
n/  — 

_  /M 

organization-name 

0 

n/  — 

n/- 

/M 

-/ri 

nvuneric-user-identif  ier 

0 

u/- 

U/- 

-/M 

pe  r  s  ona 1 -name 

0 

n/- 

-/n 

surname 

M 

M/ 

n/- 

n/- 

/M 

-/w 

given-name 

0 

M/_ 

n/  — 

n/  — 

_  /M 

-/n 

initials 

0 

M/- 
n/  — 

M/_ 
n/  — 

_/M 
~/n 

generat  ion-qual i  f  ier 

0 

n/- 

M/- 

-/n 

organi  zat  ional-uni  t-names 

0 

n/- 

M  /_ 
n/- 

_  /M 

OrganizationUnitName 

M 

M/- 

M/- 

-/M 

domain-defined-at tributes 

0 

M/ 

-/n 

Doma  i  nDe  f  i  nedAt  t  r  i  bu  t  e 

M 

M/- 

M/- 

-/M 

type 

M 

n/- 

n/  — 

/M 

-/n 

value 

M 

n/  — 

M/- 

-/M 

extension-attributes 

0 

M/- 

M/- 

-/M 

common-name 

0 

M/ 

n/- 

n/- 

/M 
-/n 

t e 1 et ex-common-name 

0 

0/- 

0/- 

-/M 

teletex-organi zat ion-name 

0 

M/- 

O/- 

-/M 

telet ex-personal -name 

0 

M/- 

0/- 

-/M 

teletex-organi zat ional-uni t- 

names 

0 

M/- 

0/- 

-/M 

teletex-domain-def ined- 

attributes 

0 

M/- 

0/- 

-/M 

pds-name 

0 

0/- 

0/- 

-/M 

physical-delivery-country-name 

0 

0/- 

0/- 

-/M 

postal-code 

0 

0/- 

0/- 

-/M 

physical-delivery-office-name 

0 

O/- 

O/- 
u/  — 

-/M 

phys  i  cal-del i  ver y-of  f  i  ce- 

number 

0 

0/- 

0/- 

-/M 

extension-OR-address- 

components 

0 

O/- 

O/- 

-/M 

pnys icax— uex i very— persona i— 

name 

0 

0/- 

0/- 

-/M 

physical-deli very- 

organ  izati  on-name 

0 

n/_ 
u/- 

n/_ 
u/  - 

_/M 
— /n 

extension— physical— deli very— 

address-components 

0 

0/- 

0/- 

-/M 

unformatted-postal-address 

0 

0/- 

0/- 

-/M 

street-address 

0 

0/- 

0/- 

-/M 

post-office-box-address 

0 

0/- 

0/- 

-/M 

poste-restante-address 

0 

0/- 

0/- 

-/M 

un  i  que-pos  t  a 1 -name 

0 

0/- 

0/- 

-/M 

local-postal-attributes 

0 

0/- 

0/- 

-/M 

extended-network-address 

0 

0/- 

0/- 

-/M 

terminal-type 

0 

0/- 

0/- 

-/M 

ORName 

MTS  to  MTS  User 

standard-attributes 

country-name 

0 

-/M 

-/M 

M/- 

Count ryName 
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Table  35  -  Classification  of  the  P3  Protocol  Elements  (continued) 


MTS  Access  Protocol  (P3) 


Part  11  of  12 


Support  by: 

IPM 

UA 

MS 

MTA 

e 

0/R 

0/R 

0/R 

Comments/Ref erences 

auiuim  s  u  To  u  ion— aoiuain*-iiciin6 

u 

-/M 

-/M 

M/- 

Doma  i  nName 

116  c WOlK— aQQres  s 

r\ 
KJ 

-/M 

-/M 

M/- 

L 1111  llaX~  1  Clcll  U  1 1. 1  x?l. 

r\ 
\J 

-/M 

-/M 

M/- 

pt  1  vate— aoiiia  1 11— nanie 

KJ 

-/M 

-/M 

M/- 

DomainName 

O  r  y  all  1  Z  a   1  on— Ilaine 

KJ 

-/M 

-/M 

M/- 

lllXlUt?!       — Uotsl  —  1  Ut;llU  1  L  1  6l 

-/M 

-/M 

M/- 

p6 1  sona  X  — ilain^ 

KJ 

-/M 

-/M 

M/- 

s>Ui  lloiu^ 

M 

n 

-/M 

-/M 

M/- 

-/M 

-/M 

M/- 

J.11X  1^  XdXa 

KJ 

-/M 

-/M 

M/- 

y  t;llt?L  d    lOll—^UctX  1 1. 1  ^X. 

KJ 

-/M 

-/M 

M/- 

oryaiii  Zat^  loncix— uni  r— najnes 

KJ 

-/M 

-/M 

M/- 

Ul^alll  ZaC  IL/llUlll  X^INalut? 

1*1 

-/M 

-/M 

M/- 

Uv^iUOL  X  ii— Ux?X  XXiC^U  — cx  XUU 

n 

-/M 

-/M 

M/- 

UkJUIcL  X  llX/tf  X  X  ll^Un  L  UX  XUUI^C 

M 

-/M 

-/M 

M/- 

type 

M 

-/M 

-/M 

M/- 

Val  U6 

M 

ri 

-/M 

-/M 

M/- 

ex^^ns  1  on— ax.  u  x  i  dux^6S 

KJ 

-/M 

-/M 

M/- 

ExtensionAt tribute 

^  \^llllu\_/l  1 — 1  IdiU 

o 

-/M 

-/M 

M/- 

u  €1 6 1 6x— coiuiuon— najne 

U 

-/M 

-/M 

M/- 

(.rCSXC  UC7A  — V^X  l^aXl  X  ^  Cl  U  X  V./11— IICUUV 

-/M 

-/M 

M/- 

"hoi  O  ^  O       r^O  T"  C/^Tl  J*  1   r%  arni^ 

Ll?Xt;  L.t;X— ]^T5X  sl^liCIX— XXdlUt? 

KJ 

-/M 

-/M 

M/- 

i-tsxts  utsx — OX  y diix        xoxidx— uiix  u  — 

XXdXl&%?o 

n 

-/M 

-/M 

M/- 

V^X^IU^A      U\_/XUC4  JL  XX  U^JLXXX^U 

J*  i"  "f"  T"  T  Vill  '1'  AC 

dw  UX  XUIXU^o 

n 

-/M 

-/M 

M/- 

L^Uk>  — XXClllly? 

-/O 

-/M 

M/- 

^ixjf  o  Xwdx— ucfx  X  vtix  jr  —  w<->u.xx  c  x  _y  — xxdxiiti 

-/o 

-/M 

M/- 

n 

-/o 

-/M 

M/- 

^IXjr  o  Xv^dX— vX^X  X  Vv7X  jr  — wX  X  X  XXdXll^ 

n 

-/O 

-/M 

M/- 

piijr  a  X  Odx— U6X  X  vex  y— Ox  X  1  oe— 

iiuiuijex 

n 

-/o 

-/M 

M/- 

exueiis  loii— Oxx— dQux  ess  — 

coniponen  t  s 

r\ 
KJ 

-/o 

-/M 

M/- 

physical-delivery-personal- 

name 

0 

-/o 

-/M 

M/- 

phys  i  cal-del i very- 

organi  zat  ion-name 

0 

-/o 

-/M 

M/- 

ext ens  ion- phys  i  cal-del i very- 

address-components 

0 

-/o 

-/M 

M/- 

unformatted-postal-address 

0 

-/o 

-/M 

M/- 

street-address 

0 

-/o 

-/M 

M/- 

post-office-box-address 

0 

-/o 

-/M 

M/- 

poste-restante-address 

0 

-/o 

-/M 

M/- 

unique-postal -name 

0 

-/o 

-/M 

M/- 

local-postal-attributes 

0 

-/o 

-/M 

M/- 

extended-network-address 

0 

-/o 

-/M 

M/- 

terminal-type 

0 

-/o 

-/M 

M/- 
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Table  36  -  Classification  of  the  P3  Protocol  Elements  (concluded) 


MTS  Access  Protocol  (P3) 


Part  12  of  12 


Notes 

1  The  MTS-user  may  interpret  any  restriction  as  simply  withhold 
*all'  submissions. 

2  No  explicit  action  needs  to  be  taken  by  the  MTA. 

3  The  MTA  may  interpret  any  restriction  as  simply  withhold  »all' 
deliveries . 

4  No  explicit  action  needs  to  be  taken  by  the  MTS-user. 

5  The  Register  operation  may  be  performed  locally  (see  X.411). 
Although  not  required  for  the  UA  for  conformance,  it  is 
considered  to  be  a  useful  service  and  support  is  recommended. 

6  The  action  to  be  taken  by  a  submitting  MTA  is  as  defined  in 
X.411  (ISO  10021-4).     In  the  absence  of  any  specific  processing 
requirements  for  a  particular  element  in  a  submission  envelope, 
the  action  to  be  taken  is  simply  the  faithful  mapping  of  such 
element  to  the  corresp>onding  element  of  the  appropriate  transfer 
envelope. 

7  The  action  to  be  taken  by  a  delivering  MTA  is  as  defined  in  X.41 
(ISO  10021-4).     In  the  absence  of  any  specific  processing 
requirements  for  a  particular  element  in  a  delivery  envelope,  the 
action  to  be  taken  is  simply  the  creation  of  such  element  from 
the  corresponding  element  of  the  appropriate  transfer  envelope. 

8  At  least  one  of  simple  and/or  strong  must  be  specified. 

9  Applies  to  ORNames  containing  Directory  Names  and/or  ORAddresses 
See  Recommendation  X.411,  section  8.2.1.1.1.14. 
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A.4      MS  Access  Protocol  (P7) 


Table  37  -  Classification  of  the  P7  Protocol  Elements 


MS  Access  Protocol  (P7) 

Part    1  of  6 

Support  by: 

IPM 

UA 

0/R 

MS 
0/R 

Protocol  Element 

S 

Comments/References 

Operations 

MSBind 
MSUnbind 

M 
M 

M/- 
M/- 

-/M 
-/M 

MSBind 

MSSE 

message-submission 
probe— submi  s  s  i  on 
cancel-deferred-delivery 

submission-control 

M 
M 
M 

M 

M/- 
n/- 

0/- 
-/M 

-/M 
—/PI 
-/M 

M/- 

See  P3  MessageSubmission 
See  P3  ProbeSubmission 
See  P3  CancelDef erred 

Delivery 
See  P3  Submi ssionControl 

MASE 
register 

change-credentials  (MS  to  UA) 
change-credentials  (UA  to  MS) 

M 
M 
M 

0/- 
-/M 
0/- 

-/M 
M/- 
-/M 

See  P3  Register 

See  P3  ChangeCredentials 

See  P3  ChangeCredentials 

MRSE 
summarize 
list 
fetch 
delete 
register-ms 
alert 

M 
M 
M 
M 
M 
M 

M/- 
M/- 
M/- 
M/- 
0/- 
-/O 

-/M 
-/M 
-/M 
-/M 
-/M 
0/- 

Summarize 

List 

Fetch 

Delete 

Register-MS 

Alert 

Arguments/Results 

MSBind 
ARGUMENT 
MSBindArgument 
initiator-name 
initiator-credentials 
simple 
strong 
security-context 
fetch-restrictions 
allowed-content-types 
allowed-EITs 
maximum-content-length 
MS-configurat ion-request 

M 
M 
M 
0 
0 
0 
0 
0 
0 
0 
0 

M/- 
M/- 
M/- 
M/- 
0/- 
0/- 
0/- 
0/- 
0/- 
0/- 
0/- 

-/M 
-/M 
-/M 
-/M 

-/o 
-/o 

-/M 
-/M 
-/M 
-/M 
-/M 
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Table  37  -  Classification  of  the  P7  Protocol  Elements  (continued) 


MS  Access  Protocol  (P7) 

Part     2  of  6 

Support  by: 

IPM 

UA 

MS 

c 

0 

0/R 

0/R 

Comments/Ref erences 

OFQFTT.T 

M 

-/M 

M/- 

rpfiriondpT*— prpdAni"  i  sis 

M 

-/M 

M/- 

sxuipxc 

w 

-/M 

M/- 

a  u  X  \jn^ 

n 

-/O 

0/- 

CI  V  61  X  XAl-'X  t?~CIU  I*  w     CI V<»  if  X  V/IAS 

o 

w 

-/M 

M/- 

1-16 

A  VAX  X  AJJXc;"a  L  CX  XL/UL'CS*  i^jf^f^o 

-/M 

M/- 

1-1024 

Q 

-/M 

0/- 

-/M 

M/- 

O  ullUllu  X  X 

5?iiTnTndri  7pArniiTnpni" 

M 

M/- 

-/M 

X  XXX.  vyx  xuA  If  X  vyxx    Jk^do  ^  y 

o 

0/- 

-/M 

Informat ionBase 

OCXC^  L.V^X 

M 

M/- 

-/M 

Selector 

summary-requests 

0 

0/- 

-/M 

1-16 

RESULT 

O  UxiUUAX  X  £ttH\X£o  U  X  U 

M 

11 

-/M 

M/- 

n 

-/M 

M/- 

M 

-/M 

M/- 

1-«7FFFFFFF'H 

0  ^  Ail 

n 

-/M 

M/- 

1  OVP  Q  ■fr 

M 

11 

-/M 

M/- 

Vi  1  nhPQ  "f" 

11  X  ^11^9 

M 
11 

-/M 

M/- 

a  UxlilllA  X  X  C  o 

-/M 

M/- 

1-16 

absPTii" 

%i  Jill/0  ^xx  \^ 

0 

-/M 

M/- 

1-'7FFFFFFF'H 

0 

-/M 

M/- 

1-32767 

t  VD6 

M 

-/M 

M/- 

value 

M 

-/M 

M/- 

count 

M 

-/M 

M/- 

List 

ARGUMENT 

List  Argument 

M 

M/- 

-/M 

informat  ion-base-type 

0 

0/- 

-/M 

Informat ionBase 

selector 

M 

M/- 

-/M 

Selector 

requested-at tributes 

0 

M/- 

-/M 

AttributeSelection 

RESULT 

ListResult 

M 

-/M 

M/- 

next 

0 

-/M 

M/- 

requested 

0 

-/M 

M/- 

Entry Informat ion. 

0_»7FFFFFFF'H 
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Table  37  -  Classification  of  the  P7  Protocol  Elements  (continued) 


MS  Access  Protocol  (P7) 

Part    3  of  6 

Support  by? 

IPM 

UA 

MS 

Protocol  Element 

S 

0/R 

0/R 

Comments/Ref erences 

Fetch 

ARGUMENT 

FetchArgument 

M 

M/- 

-/M 

information-base-type 

0 

0/- 

-/M 

Inf ormat  ionBase 

item 

M 

W~ 

-/M 

search 

0 

M/- 

-/M 

Selector 

precise 

0 

M/- 

-/M 

requested-at tributes 

0 

M/- 

-/M 

AttributeSelection 

RESULT 

M 

-/M 

M/- 

entry-information 

0 

-/M 

M/- 

Entryinf ormat ion 

list 

0 

-/M 

M/- 

0-'7FFFFFFF'H 

next 

0 

-/M 

M/- 

Delete 

ARGUMENT 

DeleteArgument 

M 

M/- 

-/M 

information-base- type 

0 

0/- 

-/O 

Inf ormat ionBase 

items 

M 

M/- 

-/M 

selector 

0 

M/- 

-/M 

Selector 

sequence-numbers 

0 

M/- 

-/M 

1-'7FFFFFFF'H 

RESULT 

DeleteResult 

M 

-/M 

M/- 

Register-MS 

ARGUMENT 

Reg  i  s  t  e  r -MS Ar  gumen t 

M 

M/- 

_/M 

auto-action-registrations 

0 

0/- 

-/O 

1-1024 

type 

M 

M/- 

-/M 

registration- identifier 

0 

M/- 

-/M 

registration-parameter 

M 

M/- 

-/M 

See  auto  action 

registration  parameters 

auto— act ion— deregi  st rat  ions 

0 

0/- 

-/o 

1-1024 

type 

M 

M/~ 

-/M 

registration-identifier 

0 

M/- 

-/M 

list-attribute-defaults 

0 

M/- 

-/M 

1-1024 

fetch-attribute-defaults 

0 

M/- 

-/M 

1-1024 

change-credentials 

0 

M/- 

-/M 

Note  1 

old-credentials 

M 

M/- 

-/M 

new-credentials 

M 

M/- 

-/M 

user-security-labels 

0 

0/- 

-/O 

1-256 

RESULT 

Register-MSResult 

M 

-/M 

M/- 
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Table  37  -  Classification  of  the  P7  Protocol  Elements  (continued) 


MS  Access  Protocol  (P7) 

Part    5  of  6 

Support  by: 

IPM 

UA 

0/R 

MS 
0/R 

Protocol  Element 

S 

Comments/References 

Common  Data  Types 

AttributeSelection 
type 
from 
count 

M 
0 
0 

M/- 
0/- 
0/- 

-/M 
-/M 
-/M 

1-32767 
1-32767 

AttributeValueAssertion 
type 
value 

M 

M 

M/- 
M/- 

-/M 
-/M 

Ent  ry Informat  i  on 
s  equence-numbe  r 
attributes 

type 

values 

M 
0 
M 
M 

-/M 
-/M 
-/M 
-/M 

M/- 
M/- 
M/- 
M/- 

1-1024 

Filter 
item 
and 
or 
not 

0 
0 
0 
0 

M/- 
0/- 
0/- 
0/- 

-/M 

-/o 
-/o 
-/o 

Filterltem 

1-32 

1-32 

Filterltem 
equality 

substrings 
type 
strings 
initial 
any 
final 
greater-or-equal 
less-or-equal 
present 

approximate-match 

0 

0 

M 
0 
0 
0 
0 
0 
0 
0 

M/- 

0/- 
M/- 
M/- 
U/- 

0/- 
0/- 
0/- 
0/- 
0/- 
0/- 

-/M 

-/o 

-/M 
-/M 
-/n 
-/M 
-/M 
-/M 
-/M 
-/M 

-/o 

AttributeValueAssertion 
(Support  is  0  if  Or name) 

AttributeValueAssertion 
AttributeValueAssertion 

Informat  ionBase 
stored-messages 
inlog 
out log 

0 
0 
0 

M/- 
0/- 
0/- 

-/M 

-/o 
-/o 
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Table  37  -  Classification  of  the  P7  Protocol  Elements  (continued) 


MS  Access  Protocol  (P7) 

Part    4  of  6 

Support  by: 

IPM 

UA 

MS 

Protocol  Element 

S 

0/R 

0/R 

Comments/References 

Alert 

ARGUMENT 

Alert  Argvunent 

M 

-/M 

M/- 

alert-registration-identifier 

M 

-/M 

M/- 

new-entry 

0 

-/M 

M/- 

Ent  r vinf ormat  ion 

RESULT 

AlertResult 

0 

M/- 

-/M 

Auto  Action  Registration 

Parameters 

AutoForwardRegistrationParameter 

filter 

0 

0/- 

-/M 

Filter 

auto-forward-arguments 

M 

M/- 

-/M 

originator-name 

M 

M/- 

-/M 

content-identifier 

0 

0/- 

-/M 

pr  ior  i  ty 

0 

0/- 

-/M 

per-message-indicators 

0 

0/- 

-/M 

See  P3 

deferred-delivery-time 

0 

0/- 

-/M 

extensions 

0 

0/- 

-/M 

See  P3 

per-recipient-f ields 

M 

M/- 

-/M 

recipient-name 

M 

M/- 

-/M 

originator-report-request 

M 

M/- 

-/M 

expl ici  t-convers  ion 

0 

0/- 

-/M 

extensions 

0 

0/- 

-/M 

See  P3 

delete-after-auto-forwarding 

0 

0/- 

-/M 

other-parameters 

0 

0/- 

-/M 

See  Note  2 

auto-forwarding-comment 

0 

0/- 

-/M 

cover -note 

0 

0/- 

-/M 

this-ipm-pref ix 

0 

0/- 

-/M 

AutoAlertRegistrationPareuneter 

filter 

0 

0/- 

-/M 

Filter 

alert-addresses 

0 

0/- 

-/o 

address 

M 

M/- 

-/M 

alert-qualifier 

0 

0/- 

-/o 

requested-at tributes 

0 

M/- 

-/M 

AttributeSelection 
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Table  37  -  Classification  of  the  P7  Protocol  Elements  (concluded) 


MS  Access  Protocol  (P7) 

Part     6  of  6 

Support  by: 

IPM 

UA 

0/R 

MS 
0/R 

Protocol  Element 

S 

Comments/References 

Range 

sequence-number-range 
from 
to 

0 
0 
0 

0/- 
0/- 
0/- 

-/M 
-/M 
-/M 

creation-time-range 
from 
to 

0 
0 
0 

0/- 
0/- 
0/- 

-/M 
-/M 
-/M 

Selector 
child-entries 
range 
filter 
limit 
override 

ooooo 

0  O  OO  o 

1  1  t  1  1 

-/M 
-/M 
-/M 
-/M 
-/M 

Range 
Filter 

Notes 

1  At  least  one  of  simple  and/or 

2  The  specified  syntax  of  other- 
only  -  see  X.413  section  12.1 

strong  must  be  specified, 
-parameters  is  for  IPMS  use 
and  X.420  section  19.4. 
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A.5     Classification  of  the  P1  Protocol  Elements  for  Security  Classes 

The  protocol  element  classifications  used  in  tables  38  and  39  should  be  viewed  as  a  delta  to  the  lower' 
security  class  or,  if  there  is  no  lower  security  class,  to  the  kernel  as  classified  in  table  34.  Thus,  table  38 
shows  the  additional  support  required  in  P1  to  conform  to  security  class  S1 .  Table  39  indicates  the  additional 
support  required  to  support  security  class  S2  (above  and  beyond  that  for  security  class  S1). 

NOTES 

1  There  are  no  additional  classifications  for  security  class  SO. 

2  The  addition  of  mandatory  content  confidentiality  does  not  affect  the  P1  protocol. 

Table  38  -  Conformance  Classification  of  the  PI  Protocol  Elements  for  Security  Class  SI 


MTS  Transfer  Protocol  (PI)  for  Security  Class  SI 


Part    1  of  2 


MT  Kernel  Static  Support  by  MTS  Class 


Protocol  Element 


B/C 
0/R 


A 
0/R 


Dyn 


Conunen  t  s /Re  f  e  r  enc  e  s 


MTABind 
ARGUMENT 
<SET> 

initiator-credentials 
simple 
strong 
bind-token 
certificate 
security-context 
RESULT 
<SET> 

responder-credentials 
simple 
strong 
bind-token 
certificate 

MessageTransf erEnvelope 
extensions 
message-security-label 


0/0 
M/M 
M/M 
0/0 
M/M 


0/0 
M/M 
M/M 
0/0 


M/M 


0/0 
M/M 
M/M 
0/0 
M/M 


0/0 
M/M 
M/M 
0/0 


M/M 


M 
X 
M 
M 

M 


M 
X 
M 
M 


M 
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Table  38  -  Conformance  Classification  of  the  Pi  Protocol  Elements  for  Security  Class  Si 

(concluded) 


MTS  Transfer  Protocol  (PI)  for  Security  Class  SI 


Part    2  of 


MT  Kernel  Static  Support  by  MTS  Class 


Protocol  Element 


B/C 
0/R 


A 
0/R 


Dyn 


Comments/References 


ReportTransferEnvelope 
extensions 

message-secur  i  ty-label 
per-recipient-f ields 
extensions 
message-token 
asynune  t  r  i  c- token 
signed-data 

message-security-label 
encrypt ed-dat a 
message-security-label 

bind-token 
asymmetric-token 
signature-algorithm-identifier 
neune 
time 

signed-data 

encrypt  ion-algor  i  thm- 
identif ier 

encrypted-data 
message-security-label 
content-integr  i  ty-key 

message-security-label 
secur  i  ty-pol i  cy- i  dent  i  f  i  er 


M/M 

0/0 

M/M 
M/M 


M/M 
M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 

M/M 
M/M 


M/M 

0/0 

M/M 
M/M 


M/M 
M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 

M/M 
M/M 


See  Note  2 


M 


M 


See  Note  2 
See  Note  2 

See  Note  1 


M 
M 
M 
M 


M 
M 


See  Note  2 


Notes 

1  In  line  with  the  CCITT  MHS  Implementors '  Guide,  the  asymmetric 
token  can  be  used  by  symmetric  and  asymmetric  techniques  as 
identified  by  the  algorithm  identifier. 

2  The  message  security  label  may  appear  in  any  or  all  of  the 
indicated  locations  in  the  envelope.  However  the  Security  context 
service  applies  only  to  the  label  in  the  "extensions"  and/or  token 
signed-data  as  defined  by  the  security  policy  in  force.  Labels  in  th 
token  encrypted  data  have  only  end-to-end  (UA-to-UA)  significance. 
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Table  39  -  Conformance  Classification  of  the  PI  Protocol  Elements  for  Security  Class  S2 


MTS  Transfer  Protocol  (PI)  for  Security  Class  S2 


Part    1  of  2 


MT  Kernel  Static  Support  by  MTS  Class 


Protocol  Element 


B/C 
0/R 


A 
0/R 


Dyn 


Comment  s /Re  f e  r ence s 


MessageTransf erEnvelope 
extension 
originator-certificate 
certificate 
certification-path 
message-origin-authentication- 
check 

algorithm-identifier 
content 

content-identifier 
message-security-label 

ProbeTr ans  f erEnvelope 
extensions 
originator-certificate 
certificate 
certification-path 
probe-origin-authentication- 
check 

algor  i  thm-i  dent  i  f  i  er 

content-identifier 

message-security-label 

ReportTransf erEnvelope 
extensions 
report ing-MTA-certificate 
certificate 
certification-path 
report-origin-authentication- 
check 

algorithm-identifier 

content-identifier 

message-secur  i  ty-label 
per-recipient 
actual-recipient-name 
originally-intended-recipient- 
name 

delivery 
message-delivery-time 
type-of-MTS-user 
recipient-certificate 
proof -of -deli very 

non-delivery 
non-delivery-reason-code 
non-delivery-diagnostic-code 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 
M/M 

0/0 
0/0 
M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
0/0 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 
M/M 

0/0 
0/0 
M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
0/0 


M 


M 


M 
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Table  39  -  Conformance  Classification  of  the  Pi  Protocol  Elements  for  Security  Class  S2 

(concluded) 


MTS  Transfer  Protocol  (PI)  for  Security  Class  S2 

Part     2  of  2 

MT  Kernel  Static  Support  by  MTS  Cle 

ISS 

A 

0/R 

Dyn 

Comments/References 

Protocol  Element 

0/R 

Certificate 
version 
serialNiimber 
signature 

algorithm 

parameters 
issuer 
validity 

notBefore 

notAf ter 
subject 

subjectPublicKeylnfo 
algorithm 
subjectPublicKey 

M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
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A.6      Classification  of  the  P3  Protocol  Elements  for  Security  Classes ; 

The  protocol  element  classifications  in  tables  40,  41 ,  and  42  should  be  viewed  as  a  delta  to  the  lower) 
security  class  or,  if  there  is  no  lower  security  class,  to  the  kerne!  as  classified  in  table  36.  Thus,  table  40' 
shows  the  additional  support  required  in  P3  to  conform  to  security  class  SO.  Table  41  indicates  the  additionali 
support  required  to  support  security  class  S1  (above  and  beyond  that  for  security  class  SO).  Table  42 
indicates  the  additional  support  required  to  support  security  class  S2  (above  and  beyond  that  for  security 
class  SI). 

NOTE  -  There  are  no  dynamic  conformance  classifications  required  by  security  class  SO  (table  40).  | 


Table  40  -  Conformance  Classsfication  of  the  P3  Protocol  Elements  for  Security  Class  SO 


MTS  Access  Protocol  (P3)  for  Security  Class  SO 

Part    1  of  2 

Static  Support  byj 

IPM 

UA 

0/R 

MS 

0/R 

MTA 
0/R 

Dyn 

Comment  s  /Re  f  e  r  ences 

Protocol  Element 

MessageDelivery 

RESULT 

proof-of -deli very 

M/- 

M/- 

-/o 

Me  s  s  ageSubm  i  s  s  i  onEn ve 1 ope 

PprRpsf  i  r>i  pntMpejcianpfiiiliTiii      i  on 

C  O  JL                 X  L/  J,  ^IJL  ^1  ICO  O  ClU  dip  LI  Jh/AU  X  O  O  X  \JLjL 

Fields 

extensions 

message-token 

M/- 

M/- 

-/O 

asymmetric-token 

M/- 

M/- 

-/o 

signature-algorithm- 

identifier 

M/- 

M/- 

-/o 

name 

M/- 

M/- 

„/0 

time 

M/- 

M/- 

„/0 

signed-data 

M/- 

M/- 

„/0 

content-confidentiality- 

algorithm-identifier 

0/- 

0/- 

-/o 

content-integrity-check 

M/~ 

M/- 

-/o 

See  Note  1 

message-security-label 

0/- 

0/- 

-/o 

procf-of -deli very-request 

M/- 

M/- 

-/o 

See  Note  1 

message-sequence-number 

0/- 

0/- 

-/o 

encryption-algorithm- 

identifier 

0/- 

0/- 

-/o 

encrypted-data 

M/- 

M/- 

-/o 

content-confidentiality- 

key 

0/~ 

0/- 

-/o 

content-integrity-check 

M/- 

M/- 

-/o 

See  Note  1 

message-security-label 

0/- 

0/- 

-/o 

content-integrity-key 

0/- 

0/- 

-/o 

message-sequence-number 

0/- 

0/- 

-/o 

content-integr  i  ty-check 

M/- 

M/- 

-/o 

See  Note  1 

proof -of -deli very-request 

M/- 

M/- 

-/o 

See  Note  1 

I 

December  1990  (Stable^i 
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Table  40  -  Conformance  Classification  of  the  P3  Protocol  Elements  for  Security  Class  SO 

(concluded) 


MTS  Access  Protocol  (P3)  for  Security  Class  SO 

Part    2  of  2 

Static  Support  by: 

IPM 

UA 

MS 

MTA 

Protocol  Element 

0/R 

0/R 

0/R 

Dyn 

Comments/References 

MessageDeliveryEnvelope 

other-fields 

extensions 

message-token 

-/M 

-/M 

0/- 

asymmetric-token 

-/M 

_/M 

0/- 

s  ignatur e-algor  i  thm- 

identi  f ier 

-/M 

-/M 

0/- 

name 

-/M 

-/M 

0/- 

time 

-/M 

-/M 

0/- 

signed-data 

-/M 

_/M 

0/- 

content -conf  i  dent  i  al i  ty- 

algorithm-identif ier 

-/O 

-/o 

0/- 

content-integrity-check 

-/M 

-/M 

0/- 

See  Note  1 

message-security-label 

-/O 

-/o 

0/- 

proof-of-deli very-request 

-/M 

-/M 

0/- 

See  Note  l 

message-sequence-number 

-/O 

-/O 

0/- 

encryption-algorithm- 

identifier 

-/o 

-/O 

0/- 

encrypted-data 

_/M 

-/M 

0/- 

cont  ent-conf  i  dent  i  al i  ty- 

key 

-/O 

-/O 

0/- 

content-integrity-check 

-/M 

-/M 

0/- 

See  Note  1 

message-security-label 

-/O 

-/O 

0/- 

content-integrity-key 

-/o 

-/O 

0/- 

mes  s  age-s  equence-numbe  r 

-/O 

-/o 

0/- 

content-integrity-check 

-/M 

-/M 

0/- 

See  Note  1 

proof-of-deli very-request 

-/M 

-/M 

0/- 

See  Note  1 

ReportDeliveryEnvelope 

PerRecipientReportDeli very- 

Fields 

extensions 

proof -of -deli very 

-/M 

-/O 

0/- 

Notes 

1    Implementations  shall  generate  no 

more  that  one  instance 

of  these 

identically-named  protocol  elements  in  a  single  message. 
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Table  41  -  Conformance  Classification  of  the  P3  Protocol  Elements  for  Security  Class  Si 


MTS  Access  Protocol  (P3)  for  Security  Class  SI 

Part    1  of  3 

Static  Support  by: 

IPM 

UA 

0/R 

MS 
0/R 

MTA 
0/R 

Dyn 

Comments/References 

Protocol  Element 

MTSBind 

MTS  to  MTS  User 

ARGUMENT 

initiator-credentials 

M 

simple 

-/o 

-/o 

0/- 

X 

strong 

-/M 

-/M 

M/- 

M 

bind-token 

-/M 

-/M 

M/- 

M 

certificate 

-/O 

-/O 

0/- 

secur  i  ty-context 

-/M 

-/M 

M/- 

M 

RESULT 

responder-credentials 

M 

simple 

0/- 

0/~ 

-/O 

X 

strong 

M/- 

M/- 

-/M 

M 

bind-token 

M/- 

M/- 

-/M 

M 

certificate 

0/- 

0/- 

-/o 

MTSBind 

MTS  User  to  MTS 

ARGUMENT 

initiator-credentials 

M 

simple 

0/- 

0/- 

-/o 

X 

strong 

M/- 

M/- 

-/M 

M 

bind-token 

M/- 

M/- 

-/M 

M 

certificate 

0/- 

0/- 

-/o 

security-context 

M/- 

M/- 

-/M 

M 

RESULT 

responder-credentials 

M 

simple 

-/o 

-/o 

0/- 

X 

strong 

-/M 

-/M 

M/- 

M 

bind-token 

-/M 

-/M 

M/- 

M 

certificate 

-/o 

-/O 

0/- 

Submi s s i onCont rol 

-/M 

M/M 

M/- 

ARGUMENT 

controls 

permissible-security-context 

-/M 

-/M 

M/- 

DeliveryControl 

M/- 

M/- 

-/M 

ARGUMENT 

controls 

permissible-security-context 

M/- 

M/- 

-/M 

Register  ^ 

ARGUMENT 

user-name 

M/- 

M/- 

-/M 

labels-and-redirections 

user-security-label 

M/- 

M/- 

-/M 

78 


Part  8:  1988  Message  Handling  Systems  December  1990  (Stable) 


Table  41  -  Conformance  Classification  of  the  P3  Protocol  Elements  for  Security  Class  SI 

(continued) 


MTS  Access  Protocol  (P3)  for  Security  Class  SI 

Part     2  of  3 

Static  Support  by: 

IPM 

UA 

0/R 

MS 
0/R 

MTA 
0/R 

Dyn 

Commen  ts /References 

Protocol  Element 

ChangeCredentials 

MTS  to  MTSuser 

ARGUMENT 

old-credentials 

M 

simple 

-/o 

-/o 

0/- 

X 

strong 

-/M 

-/M 

M/- 

M 

bind-token 

-/M 

-/M 

M/- 

M 

certificate 

-/o 

-/o 

0/- 

new-credentials 

M 

simple 

-/o 

-/o 

0/- 

X 

strong 

-/M 

-/M 

M/- 

M 

bind-token 

-/M 

-/M 

M/- 

M 

certificate 

-/o 

-/o 

0/- 

ChangeCredentials 

MTSuser  to  MTS 

ARGUMENT 

old-credentials 

M 

simple 

0/- 

0/- 

-/o 

X 

strong 

M/- 

M/- 

-/M 

M 

bind-token 

M/- 

M/- 

-/M 

M 

certificate 

0/- 

0/- 

-/o 

new-credentials 

M 

simple 

0/- 

0/- 

-/o 

X 

strong 

M/- 

M/- 

-/M 

M 

bind-token 

M/- 

M/- 

-/M 

M 

O/- 

n/- 

-/O 

MessageSubmissionEnvelope 

extensions 

message-token 

M/- 

M/- 

-/M 

signed-data 

message-security-label 

M/- 

M/- 

-/M 

See  Note  1 

secur  i  ty-pol i  cy- i  dent  i  f  i  er 

M/- 

M/- 

-/M 

M 

encrypt ed-data 

message-security-label 

0/- 

0/- 

-/o 

content— integr  i  ty— check 

M/- 

M/- 

-/M 

M 

message-security-label 

M/- 

M/- 

-/M 

See  Note 

1 

secur  i  ty-pol i  cy- i  dent  i  f  i  e  r 

M/- 

M/- 

-/M 

M 

MessageDeliveryEnvelope 

extensions 

message-security-label 

-/M 

-/M 

M/- 

See  Note 

L 

security-policy-identifier 

-/M 

-/M 

M/- 

M 

message-token 

-/M 

-/M 

M/- 

signed-data 

message-security-label 

-/o 

-/o 

0/- 

See  Note 

1 

encrypted-data 

message-security-label 

-/o 

-/O 

0/- 

See  Note 

1 
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Table  41  -  Conformance  Classification  of  the  P3  Protocol  Elements  for  Security  Class  Si 

(concluded) 


MTS  Access  Protocol  (P3)  for 

Security  Class  SI 

Part    3  of  3 

Static  Support 

by: 

IPM 

UA 

0/R 

MS 
0/R 

MTA 
0/R 

Protocol  Element 

Dyn 

Commen t s /Re f e r ence s 

ReportDeli veryEnvelope 
extensions 
message-secur  i  ty-label 

-/M 

-/M 

M/- 

M 

See  Note  1 

bind-token 
asymmetric- token 
signature-algorithm-identifier 
name 
time 

signed-data 

encrypt  ion-a Igor  i  thm- 
identif ier 

encrypt ed-dat a 
message-secur  i  ty-label 
content-integr  i  ty-key 

-/M 
-/M 
-/M 
-/M 

-/M 
-/M 
-/M 
-/M 

-/M 
-/M 
-/M 
-/M 

-/M 
-/M 
-/M 
-/M 

M/- 
M/- 
M/- 
M/- 

M/- 
M/- 
M/- 
M/- 

M 
M 
M 
M 

Notes 

1    The  message-security-label  may  appear  in  any  or  all  of  the  indicated 
locations  in  the  envelope.  However,  the  security  labelling  context 
services  apply  only  to  the  label  in  the  "extensions"  field.  Labels  in  th 
message  token  have  only  end-to-end  (UA-to-UA)  significance. 
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Table  42  -  Conformance  Classification  of  the  P3  Protocol  Elements  for  Security  Class  S2 


MTS  Access  Protocol  (P3)  for  Security  Class  S2 

Part    1  of  2 

Static  Support  by: 

IPM 

UA 

0/R 

MS 
0/R 

MTA 
0/R 

Dyn 

Comments/References 

Protocol  Element 

... 

MessageSubmission 

RESULT 

extensions 

or i gina ting— MTA— cert  i  f  icate 

-/M 

-/O 

M/- 

certificate 

-/- 

-/o 

-/- 

certification-path 

-/- 

-/o 

-/- 

proof-of-submission 

-/M 

-/o 

M/- 

MessageDeli very 

RESULT 

recipient-certificate 

TUT  / 

M/- 

M/- 

-/o 

certificate 

M/— 

TUT  / 

M/- 

-/M 

certification-path 

M/- 

M/- 

-/M 

MessageSubmi  ss  ionEnvelope 

extensions 

or iginator-certi  f icate 

M/- 

0/- 

-/M 

certificate 

-/- 

-/o 

-/- 

certification-path 

-/- 

-/o 

-/- 

message-origin- 

authent  i cat  ion-check 

M/- 

0/- 

-/M 

M 

algorithin-identi  f  ier 

M/- 

M/- 

-/M 

content 

M/- 

M/— 

/TUT 

-/M 

content — i  dent  i  f  i  e  r 

M/— 

M/  — 

-/M 

message-secur  i  ty-label 

M/- 

M/- 

-/M 

proof -of -submission-request 

M/- 

0/- 

-/M 

ProbeSubmiss ionEnvelope 

extensions 

originator-certificate 

M/- 

0/- 

-/M 

certificate 

-/- 

-/o 

-/- 

certification-path 

-/- 

-/o 

-/- 

probe-origin-authentication- 

check 

M/- 

0/- 

-/M 

M 

algor  i  thm-i  dent  i  f  i  er 

M/- 

M/- 

-/M 

content -identifier 

M/- 

M/- 

-/M 

message-security-label 

M/- 

M/- 

-/M 
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Table  42  -  Conformance  Classification  of  the  P3  Protocol  Elements  for  Security  Class  82 

(concluded) 


MTS  Access  Protocol  (P3)  for  Security  Class  S2 

Part    2  of  2 

Static  Support  by: 

IPM 

UA 

0/R 

MS 
0/R 

MTA 
0/R 

Dyn 

Comments/References 

Protocol  Element 

MessageDeliveryEnvelope 

extensions 

originator-certificate 

-/M 

-/M 

M/- 

certificate 

-/M 

-/M 

M/- 

certification-path 

-/M 

-/M 

M/- 

message-origin- 

authent  i  cat  ion-check 

-/M 

-/M 

M/- 

M 

algorithm-identifier 

-/M 

-/M 

M/- 

content 

-/M 

-/M 

M/- 

content-identifier 

-/M 

-/M 

M/- 

message-security-label 

-/M 

-/M 

M/- 

ReportDeliveryEnvelope 

extens  ions 

report ing-MTA-certificate 

-/M 

-/O 

M/- 

certificate 

-/- 

-/o 

-/- 

certification-path 

-/- 

-/o 

-/- 

report-origin-authentication- 

check 

-/M 

-/o 

M/- 

M 

PerRecipientReportDeli very- 

Fields 

extensions 

recipient-certificate 

-/M 

-/M 

0/- 

certificate 

-/M 

-/M 

M/- 

certification-path 

-/M 

-/M 

M/- 

Certificate 

version 

-/M 

-/M 

M/- 

sen  ax  IN  uniD6  r 

-/M 

/TUT 

TUT  / 

n/- 

signature 

-/M 

-/M 

M/- 

algorithm 

-/M 

-/M 

M/- 

parameters 

-/o 

-/o 

0/- 

issuer 

-/M 

-/M 

M/- 

validity 

-/M 

-/M 

M/- 

notBefore 

-/M 

-/M 

M/- 

not After 

-/M 

-/M 

M/- 

subject                          ^  ■ 

-/M 

-/M 

M/- 

sub jectPublicKey Info 

-/M 

-/M 

M/- 

algorithm 

-/M 

-/M 

M/- 

sub jectPublicKey 

-/M 

-/M 

M/- 
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I  Table  43  presents  the  classification  delta  to  classification  tables  40,  41,  and  42,  for  the  addition  of 
'j  mandatory  content  confidentiality  in  the  static  conformance  classification. 

NOTE  -  There  are  no  dynamic  conformance  classification  required  by  the  addition  of  content 
confidentiality. 


Table  43  -  Conformance  Classification  of  the  P3  Protocol  Elements  for  Security  Classes  SOa,  SI  a, 

or  S2a 


MTS  Access  Protocol  (P3)  for  Security  Classes  SOa,  Sla,  S2a 

Part    1  of  1 

TDM 

no 

ni  A 

U/  I\ 

L/yii 

Commen  ts/References 

ne  s  s  a  y  6  b  u  DID  1 5  s  1  onj!in  ve  X  ops 

algorithm-identifier 

M/- 

0/- 

-/o 

message-token 

asymmetric-token 

signed-data 

M/- 

-/- 

-/- 

cont en  t-conf  i  dent  i  al i  ty- 

algorithm-identif ier 

M/- 

-/- 

-/- 

encrypted-data 

content-confidentiality- 

key 

M/- 

-/- 

-/- 

MessageDeliver  yEn v  e 1 ope 

extensions 

message-token 

-/M 

-/M 

0/- 

asymmetric-token 

signed-data 

-/M 

-/M 

-/- 

cont ent-conf  i  dent  i  al i  ty- 

algorithm-identif ier 

-/M 

-/M 

-/- 

encrypted-data 

content-confidentiality- 

key 

-/M 

-/M 

-/- 

content-confidentiality- 

algorithm-identifier 

-/M 

-/M 

0/- 

Notes 

1    Implementors  shall  generate  no  more  than  one  instance  of 
identically  named  protocol  elements  in  a  single  message. 

these 

A.7     Classification  of  the  P7  Protocol  Elements  for  Security  Classes 

j    The  protocol  element  classifications  in  table  44  should  be  viewed  as  a  delta  to  the  lower  security  class 

or,  if  there  is  no  lower  security  class,  to  the  kernel  as  classified  in  table  37.  Thus,  table  44  shows  the 
I    additional  support  required  in  P7  to  conform  to  security  class  31 . 

NOTES 
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1  There  are  no  additional  classifications  for  security  classes  SO  and  S2. 

2  The  addition  of  nnandatory  content  confidentiality  does  not  affect  the  P7  protocol. 


Table  44  -  Conformance  Classification  of  the  P7  Protocol  Elements  for  Security  Class  81 


MS  Access  Protocol  (P7)  for  Security  Class  SI 

Part    1  of  1 

Static  Support  by: 

IPM 

UA 

0/R 

MS 
0/R 

Dyn 

Comments/References 

Protocol  Element 

MSBind 

ARGUMENT 

initiator-credentials 

M 

simple 

0/- 

-/O 

X 

strong 

M/- 

-/M 

M 

bind-token 

M/- 

-/M 

M 

certificate 

0/- 

-/O 

security-context 

M/- 

-/M 

M 

RESULT 

responder-credentials 

M 

simple 

-/O 

0/- 

X 

strong 

-/M 

M/- 

M 

bind-token  , 

-/M 

M/- 

M 

certificate 

-/o 

0/- 

Register-MS 

ARGUMENT 

Register -MS Ar  gumen t 

changeCredent ials 

M 

old-credentials 

M/- 

-/M 

M 

simple 

0/- 

-/o 

M 

strong 

M/- 

-/M 

X 

bind-token 

M/- 

-/M 

M 

certificate 

0/- 

-/O 

new-credentials 

M/- 

-/M 

M 

simple 

0/- 

-/o 

X 

strong 

M/- 

-/M 

M 

bind-token 

M/- 

-/M 

M 

certificate 

0/- 

-/o 

user-security-labels 

M/- 

-/M 

M 

message-security-label 

secur ity-pol icy- i dent i  fier 

M/- 

-/M 

M 

security-classification 

M/- 

-/M 

privacy 

0/- 

-/o 

security-categories 

M/- 

-/M 
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A.8     Message  Store  General  Attribute  Support 


Table  45  -  Classification  of  the  Message  Store  General  Attributes 


Message  Store  General  Attribute  Support 

Part  1  of  2 

Support  by; 

IPM 

UA 

Rec 

Bas 

MS 

Org 

IPM 

MS 

Org 

Attribute 

s 

Comments /References 

chi Id— sequence— numbers 

M 

M 

M 

M 

content 

M 

M 

M 

M 

content— conf  i  dent  i  al i  t v— 

al  aciT  i  t"hin— i  dAnt  i  f  i  at 

0 

0 

0 

0 

content— cor relator 

0 

0 

0 

M 

cr>n  t"  pnt  —  i  dpnt  i  f  i  p  r 

0 

o 

o 

M 

content- intear  i  tv— check 

0 

0 

0 

0 

content— lenath 

0 

o 

o 

w 

M 

content— returned 

0 

0 

0 

M 

content— t  vise 

M 

M 

M 

M 

convers  ion— wi  th— loss— prohibi  ted 

0 

0 

0 

M 

converted-eits 

0 

0 

0 

M 

creat  ion-time 

M 

M 

M 

M 

del i  vered— ei  t s 

0 

0 

H 

M 

delivery— flags 

0 

0 

6 

M 

dl— expansion— history 

0 

0 

0 

M 

entry— status 

M 

M 

M 

M 

entry- type 

M 

M 

M 

M 

int  ended- reci  pi  ent-neune 

0 

0 

0 

M 

message-delivery-envelope 

M 

M 

M 

M 

message— deli very— i dent i  fier 

r\ 
U 

0 

0 

M 

message-del i very- 1  i me 

0 

0 

0 

M 

message-origin-authentication- 

check 

0 

0 

0 

0 

message-secur  i  ty-label 

0 

0 

0 

0 

message-submi  ss  ion-t  ime 

0 

0 

0 

M 

message-token 

0 

0 

0 

0 

original-eits 

0 

0 

0 

M 

originator-certificate 

0 

0 

0 

0 

originator-name 

0 

0 

0 

M 

other-recipient-names 

0 

0 

0 

M 

parent-sequence-number 

M 

M 

M 

M 

per-recipient-report-deli very- 

fields 

M 

M 

M 

M 

priority 

0 

0 

H 

M 

proof -of -del i very-request 

0 

0 

0 

0 

redirection-history 

0 

0 

0 

M 

report-delivery-envelope 

M 

M 

M 

M 

report ing-dl -name 

0 

0 

0 

H 

report ing-mta-certificate 

0 

0 

0 

6 
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Table  45  -  Classification  of  the  Message  Store  General  Attributes  (concluded) 


Message  Store  General  Attribute  Support 

Part  2  of  2 

Support  by: 

IPM 

UA 

Rec 

Bas 

MS 

Org 

IPM 

MS 

Org 

Attribute 

S 

Comments/References 

report-origin-authentication- 
check 

security-classification 
sequence-number 
subject-submission-identifier 
this-recipient-name 

0 
0 
M 
M 
0 

0 
0 
M 
M 
0 

0 
0 
M 
M 
0 

0 
0 
M 
M 
M 

Note  -    Enhanced  MS  support  for  optional  Functional  Groups  is  for 
further  study.  Attributes  which  are  relevant  to  these  areas  are 
currently  specified  as  Unsupported. 

f 
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A.9      Classification  of  the  IPM  MS  General  Attributes  for  Security 
Classes 

The  classification  of  tfie  attributes  in  table  46  is  a  delta  to  the  MS  General  Attributes  classified  in  table  38. 
Table  46  indicates  the  additional  attributes  that  must  be  supported  in  the  IPM  MS  for  each  of  the  security 
classes.  There  is  no  support  required  for  security  attributes  in  the  basic  MS. 


Table  46  -  IPM  MS  Security  Attribute  Support 


Security  Class 

Attribute 

SO 

SOa 

SI 

Sla 

S2 

S2a 

content-conf  i  dent  i  al i  ty-algor  i  thm- 

identif ier 

0 

M 

0 

M 

0 

M 

content- integrity-check 

M 

M 

M 

M 

M 

M 

message-secur i ty-label 

0 

0 

M 

M 

M 

M 

message-orig in-authentication-check 

M 

M 

M 

M 

M 

M 

message-token 

M 

M 

M 

M 

M 

M 

origination-certificate 

0 

0 

0 

0 

M 

M 

proof-of-delivery 

M 

M 

M 

M 

M 

M 

report ing-mta-certificate 

0 

0 

0 

0 

M 

M 

report-origin-authentication-check 

0 

0 

0 

0 

M 

M 

security-classification 

0 

0 

M 

M 

M 

M 
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A.10    Message  Store  IPM  Attribute  Support 

This  clause  is  to  be  read  in  accordance  with  Annex  C  of  X.420  (1988). 


Table  47  -  Classification  of  the  Message  Store  IPM  Attributes 


Message  Store  IPM  Attribute  Support 

Part  1  of  2 

Support  by: 

IPM 

UA 

Rec 

IPM 

MS 

Org 

Attribute 

S 

Comments/References 

Summary  Attributes: 

ipm-entry-type 

0 

0 

M 

ipm- synopsis 

0 

0 

M 

Heading  Attributes: 

author i zing-users 

0 

0 

M 

auto-forwarded 

0 

0 

M 

bl ind— copy— r ec  i  pi  ent  s 

0 

0 

M 

copy-recipients 

0 

0 

M 

expiry-time 

0 

0 

M 

heading 

M 

M 

M 

importance 

0 

0 

M 

incomplete-copy 

0 

0 

0 

languages 

0 

0 

M 

nrn-requestors 

0 

0 

M 

obsoleted-ipms 

0 

0 

M 

originator 

0 

0 

M 

primary-recipients 

0 

0 

M 

related-ipms 

0 

0 

M 

replied- to- ipm 

0 

0 

M 

reply-recipients 

0 

0 

M 

reply-requestors 

0 

0 

M 

reply-time 

0 

0 

M 

rn-requestors 

0 

0 

M 

sensitivity 

0 

0 

M 

subject 

0 

0 

M 

this-ipm 

M 

M 

M 

Body  Attributes: 

bilaterally-def ined-body- 

parts 

0 

0 

0 

body 

M 

M 

M 

encrypted-body-parts 

0 

0 

0 

encrypt ed-dat a 

0 

0 

0 

encrypt ed-parameters 

0 

0 

0 

extended-body-part- types 

0 

0 

0 
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Table  47  -  Classification  of  the  Message  Store  IPM  Attributes  (concluded) 


Message  Store  IPM  Attribute  Support 

Part  2  of  2 

Support  by: 

IPM 

UA 

Rec 

IPM 

MS 

Org 

Attribute 

S 

Comments/References 

g3-f acsimile-body-parts 

0 

0 

0 

g3-f acsimile-data 

0 

0 

0 

g3-f acsimile-parameters 

0 

0 

0 

g4-classl-body-parts 

0 

0 

0 

ia5-text-body-parts 

0 

0 

M 

ia5-text-data 

0 

0 

0 

ia5- text-parameters 

0 

0 

0 

message-body-parts 

0 

0 

M 

message— Qat a 

u 

0 

0 

message-parameters 

0 

0 

0 

mixed-mode-body-parts 

0 

u 

U 

nationally-def ined-body-parts 

0 

0 

0 

telet ex-body-parts 

0 

0 

0 

teletex-data 

0 

0 

0 

telet ex-parameters 

0 

0 

0 

videotex-body-parts 

0 

0 

0 

videotex-data 

0 

0 

0 

videotex-parameters 

0 

0 

0 

voice-body-parts 

0 

0 

0 

voice-data 

0 

0 

0 

voice-parameters 

0 

0 

0 

Notification  Attributes: 

acknowledgment -mode 

0 

0 

M 

auto-forward-comment 

0 

0 

M 

conve  r  s  i  on-e  its 

0 

0 

M 

discard-reason 

0 

0 

M 

ipm-prefer red-recipient 

0 

0 

M 

ipn-originator 

0 

0 

M 

non-receipt-reason 

0 

0 

M 

receipt-time 

0 

0 

M 

returned-ipm 

0 

0 

0 

sub ject-ipm 

M 

M 

M 

suppl-receipt-inf o 

0 

0 

0 
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A.11     EDI  Messaging  Service  Protocol  (Pedi) 

See  Working  Document. 
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A.I 2    Message  Store  EDIMS  Attribute  Support 

See  Working  Document. 
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Annex  B  (normative) 


List  of  ASN.1  Object  Identifiers 
B.I      Content  Types 

See  Working  Document. 

B.2      Body  Part  Types 

See  Working  Document. 

B.3      Security  Classes 

Tlie  ASN.1  expressed  in  figure  15  defines  the  security  Object  Identifiers  specified  by  these  Implementation 
Agreements.  These  are  the  same  as  defined  in  the  EWOS/ETSI  A/3311  profile. 


id-mhs-security  OBJECT  IDENTIFIER  ::=  {  iso  (1) 

identif ied-organization  (3)  ewos  (16)  eg  (2)  mhs  (4)  security  (4)  } 


id-policy- id 
id-category- id 


OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 


—  Security  Policy  Object  Identifiers  — 


secur ity-class-0 
security-class-Oa 
secur ity-class-1 
security-class-la 
secur ity-class-2 
secur ity-class-2a 


OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 


—  Security  Category  Object  Identifiers  — 


private-id 
confidence-id 

coittmercial-in-conf  idence-id 
management -in-confidence-id 
per sonal-in-conf idence-id 


OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 


;=  f  id-mhs-security  1  ) 
;=  {  id-mhs-security  2  } 


=  {  id-policy-id  0  } 

=  {  id-policy-id  0  1} 

=  {  id-policy-id  1  ) 

=  f  id-policy-id  11} 

=  {  id-policy-id  2  } 

=  {  id-policy-id  2  1} 


=  { 
=  { 

:[ 

=  { 


id-category-id  0 

id-category-id  1 

id-category-id  2 

id-category-id  3 

id-category-id  4 


Figure  15  -  Security  Object  Identifiers 
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Annex  C  (informative)  

Interpretation  of  Elements  of  Service 

The  ob)0CtiV0  <rf  thl$  0iaU$Q  ^  to  ptct^lxi^  clarlflc  nctlonaltty  of  Elements  cA 

Service  where  the  MHS  standards  are  unclesK-  c  ..^^nt  of  this  clause  to  define 

how  iftformaSott  should  1)0  msd^  av^M^e  or  pi  ->.^.  .w-  ,  .or  is  it  Intended  to  define  how 

iindfvlduai  vendoi^  should  design  th^  productSx 

The  ft^ov^g  MHS  Bemerrts  of  Ser^fee  require  ftjrther  text  to  be  added  to  their  deBnitlons  to  represent 
the  prcp:i$ed  imj^erri^^tion  of  iti6$e  vio$:  for  <Jo»fOf m$tio$  to  this  Agreemer^t 

Q€»nent$  of  Service  wNc^  are  fiOt  referet^ced  m  tliis  clause  are  as  defined  m  the  IVIHS  base  standards* 

Ref^  Request  Indlcatictfi:  The  re^^'feclpFerts  and  the  reply-^lme  may  tje  ^ctSed  wlthotrt  any  explicit 
reply  being  requested.  This  n^ay  b^  inti^preted  by  the  f  eolptent  as  an  Implicit  rei^y  reciuest. 

NO"  "       '  an  arfo^arwarded  massage,  an  'explicit  or  Jmplldt  r^ly  request  may  nor  be  meaningful. 

Forwarded  tP-meseage  indloatlcmt  The  Ibliovt^ng  use  of  the  orlQlnat  encoded  Information  t/pe  In  the 
context  of  forwarded  messages  Is  dteirif led; 

a)  Ttie  encoded  Infonmtlon  types  of  8he  message  b^ng  forwarded  shcHJid  be  rejected  in  the 
new  otiglnal  encoded  Infc^ntatlon  types  b^lng  generated^ 

b)  forwarding  a  ptlvatety  defined  body  part  (see  figure  4),  the  originator  of  the  forwarding 
rnessage  €^all  set  ibe  c^iglnal  encoded  Information  t^s  in  the  PI  envelope  to  Underfined  for 
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Annex  D  (informative) 


Recommended  Practices 

This  clause  provides  guidelines  on  areas  not  addressed  by  the  base  standards.  These  guidelines  have 
been  produced  in  order  to  promote  awareness  of  interim  solution  to  problems  as  agree  by  members  of 
the  OIW  X.400  SIG.  However  implementors  of  these  recommended  practices  should  note  that  it  is  not 
necessary  to  follow  the  recommended  practices  when  claiming  conformance  to  these  agreements. 

Implementors  should  also  note  that  future  standardization  by  CCITT  and  ISO/IEC  on  area  covered  by 
this  clause  may  result  in  different  solutions  to  those  proposed  in  this  clause. 


D.I      Printable  String 

There  are  existing  mail  systems  that  include  a  small  set  of  non-Printable  String  characters  in  their 
identifiers.  For  these  systems  to  communicate  with  MHS  systems,  either  for  pass-through  service  or 
delivery  to  MHS  users,  gateways  will  be  employed  to  encode  these  special  characters  into  a  sequence 
of  Printable  String  characters.  This  conversion  should  be  performed  by  the  gateway  according  to  a 
common  scheme  and  before  insertion  in  Domain  Defined  Attributes,  which  are  intended  to  carry 
electronic  mail  identifiers.  MHS  UAs  may  also  perform  such  conversions. 

It  is  recommended  that  the  following  symmetrical  encoding  and  decoding  algorithm  for  non-Printable 
String  characters  be  employed.  The  encoding  algorithm  maps  an  ASCII  representation  to  a 
PrintableString  representation.  Any  non-printable  string  characters  not  specified  in  table  50  are  covered 
by  the  category  "other". 


Table  50  -  Printable  String  to  ASCII  Mapping 


ASCII  Character 

Printable  String  Character 

%  (percent) 

(P) 

@   (at  sign) 

(a) 

!  (exclamation) 

(b) 

"   (quote  mark) 

(q) 

_  (underline) 

(u) 

(   (left  paren.) 

(1) 

)    (right  paren. ) 

(r) 

other 

(3DIGIT) 

where  3DIGIT  has  the  range  000  to  377  and  is  interpreted  as  the  octal  encoding  of  an  ASCII  character. 

To  encode  an  ASCII  representation  to  a  PrintableString,  table  50  and  the  algorithm  in  figure  16  should  be 
used. 
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IF  current  character  is  in  the  encoding  set  THEN 

encode  the  character  according  to  table  50 
ELSE 

write  the  current  character; 
continue  reading; 


Figure  16  -  ASCII  to  PrintableStrIng  Algorithm. 

To  decode  a  PrintableString  representation  to  an  ASCII  representation,  table  50  and  the  algorithm  in 
figure  17  should  be  used. 


IF  current  character  is  not  THEN 

write  character 
ELSE 

{ 

look  ahead  appropriate  characters; 

IF  composite  characters  are  in  table  50  THEN 

decode  per  table  50 
ELSE 

write  current  character; 
} 

continue  reading; 


Figure  17  -  PrintableString  to  ASCII  Algorithm. 


D.2     Rendition  of  lASText 

The  characters  that  may  be  used  in  an  lASString  are  the  graphic  characters  (including  Space),  control 
ll  characters  and  Delete  of  the  IA5  character  repertoire  ISO  646. 

■  The  graphic  characters  that  may  be  used  with  a  guaranteed  rendition  are  those  related  with  positions 
2/0  to  2/2,  2/5  to  3/15,  4/1  to  5/10,  5/15  and  6/1  to  7/10  in  the  basic  7-bit  code  table. 

I'  The  other  graphic  characters  may  be  used  but  have  no  guaranteed  rendition. 

The  control  characters  that  may  be  used  but  have  no  guaranteed  effect  are  a  subset  consisting  of  the 
j  format  effectors  0/10  (LF),  0/12  (FF)  and  0/13  (CR)  provided  they  are  used  in  one  of  the  following 
combinations  as  defined  in  table  51. 


Table  51  -  Interpretation  of  Format  Effector  Combinations. 


Combination 

Interpretation 

CR  LF 
CR  FF 
LF   . .  LF 

to  start  a  new  line 
to  start  a  new  page  (and  line) 
to  show  empty  lines  (always  after  one  of  the 
preceding  combinations). 

The  other  control  characters  or  the  above  control  characters  in  different  combinations  may  be  used  but 
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The  character  Delete  nnay  occur  but  has  no  guaranteed  effect.  The  lASString  in  a  P2  lASText  BodyPart 
represents  a  series  of  lines  which  may  be  divided  into  pages.  Each  line  should  contain  from  0  to  80 
graphic  characters  for  guaranteed  rendition.  Longer  lines  may  be  arbitrarily  broken  for  rendition. 

NOTE  -  X.408  states  that  for  conversion  from  lASText  to  Teletex,  the  maximum  line  length  is  77 
characters. 


D.3      EDI  Use  of  MHS 


D.3.1       Introduction  and  Scope 

This  clause  presents  a  carry-forv\^ard  of  the  Recommended  Practices  in  Part  7  of  the  OIW  Stable 
Implementation  Agreements  for  support  of  EDI  data  transfer  in  an  MHS  (1988)  environment.  These 
recommended  practices  outline  an  interim  procedure  for  use  in  transferring  EDI  transactions  between 
trading  partner  applications  in  order  to  facilitate  further  MHS  implementation  by  EDI  users.  It  is  the 
stated  objective  of  the  OIW  X.400  SIG  to  migrate  towards  the  CCITT  target  solution  of  P^di  once  it  is 
defined  (currently  expected  to  be  completed  by  late  1990).  The  approach  for  carrying  EDI  interchanges 
over  MHS  systems  as  recommended  in  this  clause  provides  a  mechanism  for  a  smooth  migration  to  the 
target  CCITT  P^d,  solution. 

The  scope  of  this  guideline  is  to  describe  specific  recommended  practices  for  extending  MHS  as  a  data 
transfer  mechanism  between  EDI  applications.  This  interim  solution,  as  in  the  existing  X.400  (1984) 
Agreements,  is  referred  to  as  the  PO  approach  and  differs  slightly  from  the  European  solution  which  uses 
a  P2  mechanism  to  package  the  EDI  data  stream.  However,  if  adhered  to,  PO  messages  may  be 
delivered  to  P2  recipients  and  vice-versa,  by  the  MTA  making  a  minor  envelope  conversion  as 
recommended  in  this  clause. 


li 


D.3.2 


Model 


The  model  used  is  consistent  with  that  defined  in  clause  7.12.5  of  the  Agreements  for  X.400  (1984) 
systems,  with  several  minor  exceptions.  As  before,  the  model  provides  for  a  peer-to-peer  EDI 
Messaging  (EDIM)  UA  service. 


EDI  User 
Application 


EDIM 
UA 

MTS 

EDIM 
UA 

EDI  User 
Application 


Figure  18  -  EDI  Messaging  Functional  Model. 

In  figure  18,  the  EDIM  UA  may  support  delivery  of  EDI  messages  formatted  according  to  the  OIW  PO 
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(1988),  PO  (1984),  P2  (1984)  or  P22  (1988)  Agreements.  It  is  recommended  that  implementations 
supporting  EDI  over  MHS  generate  PO  formatted  messages  as  described  below,  but  be  prepared  to 
deliver  any  of  tlie  four  recognized  formats  for  which  Agreements  have  been  achieved.  Whether  the  EDI 
transaction  is  carried  using  the  PO  or  P2  (1988  or  1984)  approaches,  the  EDI  content  is  restricted  to  be 
only  one  EDI  interchange  per  MHS  message.  The  OIW  approach  carries  forward  the  1984  X.400 
recommended  practices  as  a  interim  intenvorking  solution.  The  use  of  object  identifiers  in  either  the  EIT 
or  Content  Type  fields  is  not  recommended  due  to  the  current  definition  of  the  1984  interworking  rules 
specified  in  CCITT  Recommendation  X.419  (see  clause  3.3  of  annex  C). 

The  EDIM  UA  must  support  the  essential  MT  and  MS  Elements  of  Service  as  defined  in  this  Agreement. 
It  is  recognized  that  a  Message  Store  may  not  convey  much  information  to  a  remote  EDIM  UA  with  the 
PO  approach.  It  is  further  recognized  that  MS  Elements  of  Service  are  not  necessarily  made  available  by 
the  EDIM  UA  to  the  EDI  user  application. 


D.3.3       Protocol  Elements  Supported  for  EDI 

The  following  PI  protocol  elements  will  be  used  as  a  minimum  to  support  EDI  applications: 

Content  Type:  For  EDIM  applications,  the  content  type  will  continue  to  be  as  specified  in  clause  7.12.5.3 
of  the  OIW  Stable  Agreements  for  X.400  (1984),  i.e..  Undefined  (0).  The  interchange  contained  in  the  PI 
envelope  and  identified  by  this  Content  Type  is  carried  as  an  octet  string. 

NOTE  -  For  intenworking  with  1984  X.400  systems,  the  use  of  an  externally  registered  object  identifier  is 
not  recommended.  Such  use  would  create  interworking  problems  as  well  as  loss  of  information  when  the 
X.419  downgrading  rules  are  applied.  In  the  current  definition  of  the  latter,  an  object  identifier  would  be 
mapped  to  the  Content  Type  value  of  1  (External),  instead  of  0  (Undefined).  Additionally,  the  downgrading 
rules  require  the  object  identifier  value  to  be  inserted  into  the  Content,  which  would  cause  further 
intenworking  problems  since  1984  EDIM  UAs  will  expect  only  the  EDI  interchange  in  the  Content. 

Original  Encoded  Information  Types  (EITs):  EDIM  applications  will  continue  to  use  the  EITs  as  specified 
in  clause  7.12.5.3  of  the  OIW  Stable  Agreements  for  X.400  (1984),  i.e.,  IA5Text  and  Undefined  (for 
EBCDIC  encoding).  However,  it  is  recognized  that  any  EIT  defined  in  the  1988  MHS  standards  may  be 
used  to  specify  the  encodings  of  the  EDI  content. 

NOTE  -  For  interworking  with  1984  X.400  systems,  the  use  of  an  externally  registered  object  identifier 
signify  the  EDI  encoding  is  not  recommended.  According  to  the  current  definition  of  the  downgrading 
rules  in  CCITT  Recommendation  X.419,  a  1988  MTA  must  downgrade  an  object  identifier  to  Undefined  and 
then  discard  the  object  identifier.  Such  loss  of  EDI  encoding  information  conflicts  with  the  existing 
Agreements  for  X.400  (1984)  systems  that  the  semantics  of  the  Undefined  EIT  is  always  EBCDIC. 


D.3.4       Addressing  and  Routing 

As  in  the  Stable  Implementation  Agreements  for  X.400  (1984),  EDI  messages  entering  a  1988  MHS 
environment  will  need  to  have  MHS  0/R  Names  and/or  0/R  Addresses  in  the  PI  envelope  to  identify 
the  originator  and  recipient  trading  partners.  The  mapping  of  the  EDI  originator  and  recipient 
interchange  addresses  to  an  0/R  Name  or  0/R  Address  may  be  achieved  either  by  local  means  or 
through  services  provided  by  the  OSI  Directory  (see  part  9,  clause  1). 
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If  the  EDI  message  Is  originated  and  delivered  without  transitting  a  X.400  (1984)  MTA,  then  any  of  the 
0/R  Address  forms  specified  in  this  Agreement  may  be  used.  However,  since  it  cannot  be  assumed 
that  EDI  messages  will  never  transit  an  X.400  (1984)  MTA,  it  will  often  be  useful  to  include  additional 
Domain  Defined  Attributes  as  specified  in  clause  7.12.5.4  of  the  Stable  Agreements.  This  DDA  is  needed 
to  ensure  that  a  message  is  deliverable  to  an  EDIM  UA  associated  with  a  X.400  (1984)  MTA  and  that 
delivery  and  receipt  reports  can  be  flagged  as  a  new  report  type. 


D.4     Textual  Representation  of  0/R  Names 

See  Working  Document. 


D.5      ODA  Transfer 

See  Working  Document. 


D.6     Use  of  Externally  Defined  Body  Part 

The  Externally  Defined  Body  Part  allows  the  identification  of  various  types  of  information  exchanged 
between  UAs.  This  capability  allows  a  UA  on  reception  to  recognize  the  appropriate  application  to 
process  the  information,  e.g.,  to  automatically  invoke  the  application.  It  also  allows  the  MTS  to  possibly 
convert  from  one  type  to  another  (e.g.,  to  convert  a  word-processing  document  to  ODA).  For  example,  a 
spreadsheet  application  on  a  personal  computer  from  vendor  A  by  operating  system  X  can  send  via 
X.400  to  the  UA  on  workstation  from  vendor  B  using  operating  system  Y,  and  the  latter  will  be  able  to 
recognize  and  possible  invoke  the  appropriate  spreadsheet  application  to  process  the  data. 

The  Externally  Defined  Body  Part  definition  is  reproduced  in  figure  19. 
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External lyDefinedBodyPart 
parameters 
data 

ExternallyDef inedParameters 
External lyDefinedData 

EXTERNAL 

direct-reference 
indirect-reference 
data-value-descriptor 
encoding 

single-ASNl-type 

octet-aligned 

arbitrary 


SEQUENCE  { 

[0]  ExternallyDef inedParameters  OPTIONAL, 
ExternallyDef inedData  } 

EXTERNAL 
EXTERNAL 

[UNIVERSAL  8]     IMPLICIT  SEQUENCE  { 
OBJECT  IDENTIFIER  OPTIONAL, 
INTEGER  OPTIONAL, 
ObjectDescriptor  OPTIONAL, 
CHOICE  { 
[0]  ANY, 

[1]     IMPLICIT  OCTET  STRING. 
[2]     IMPLICIT  BIT  STRING     }  } 


Note  -    In  the  case  of  transfer  of  EXTERNAL  in  P2  BodyPart,  the 
direct-reference  component  is  mandatory  and  the  indirect-reference  and 
data-value-descriptor  components  must  be  absent. 


Figure  19  -  Externally  Defined  Body  Part  Definition. 


The  following  recommends  how  to  use  the  components  of  this  BodyPart: 

a)  Use  of  Parameters  component:  In  simple  cases,  to  ease  the  integration  of  applications  to 
X.400  systems,  the  Parameters  component  need  not  be  used; 

b)  Use  of  Data  component:  For  each  different  format  of  data,  different  Object  Identifiers  for  the 
Data  component  are  recommended.  If  an  application  chooses  to  use  ASN.1  to  format  the  data 
to  achieve  a  single  representation  across  platforms,  the  single-ASN1-type  encoding  choice 
should  be  used.  OtheoA/ise: 


1)  The  octet-  (i.e.,  byte)  aligned  choice  is  used  if  the  data  format  is  octet-aligned; 


2)  The  arbitrary  choice  is  used  if  the  data  is  bit-aligned; 


c)  Assignment  of  Object  Identifiers:  Object  Identifiers  need  to  be  assigned  for  the  EXTERNALS, 
and  these  identifiers  for  the  Parameters  and  Data  components  should  be  different.  The  Object 
Identifier  for  an  EXTERNAL  also  indicates  the  syntax  of  the  data  encoding,  i.e.,  whether  single- 
ASNl-type  or  octet-aligned  or  bit-aligned  is  being  used. 


NOTE  -  Whether  the  Object  Identifier  needs  to  be  present  in  this  case  is  for  further  study. 


There  are  many  ways  to  obtain  object  identifiers.  One  such  way  is  described  as  follows: 

a)  The  application  provider  obtains  a  unique  Numeric  Name  form  for  their  organization  from 
ANSI,  as  described  in  ANSI  ISSB  840  and  ISSB  843,  and  appends  this  number  form  to  {iso  (1) 
member-body  (2)  US  (840)}  to  form  an  object  identifier  denoting  their  organization. 

b)  The  application  provider  (organization)  allocates  a  series  of  numbers  to  identify  the 
application  data  format;  these  numbers  are  appended  to  the  object  identifier  constructed  in  step 
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(i)  to  form  an  object  identifier  that  is  globally  unique.  It  Is  recommended  that  the  application 
provider  (organization)  use  a  hierarchical  structure  for  identifying  their  data  types  to  ease  the 
administration  of  the  identifiers. 

For  example,  company  PCSoftware  Inc.  obtains  the  organization  number  "999"  from  ANSI.  The 
PCSoftware  Spreadsheet  file  for  MS-DOS  might  be  assigned  the  following  object  identifier. 

NOTE  -  ASN.1  notation  is  used.  The  numbers  in  parentheses  form  the  identifier,  the  associated  words 
describe  the  number. 

{  iso  (1)  member-body  (2)  US  (840)  PCSoftware  Inc.  (999)  J^S-DOS-Application  (1)  Spreadsheet 
(3)  Data  (1)  } 

Since  the  Spreadsheet  data  format  for  MS-DOS  does  not  follow  ASN.1  encoding  rules  and  is  octet- 
aligned,  the  encoding  choice  for  the  Data  EXTERNAL  is  octet-aligned. 

It  is  also  recognized  that  not  ail  objects  will  be  registered  as  indicated  above.  In  order  to  transfer 
unregistered  data,  It  is  recommended  that  they  be  transferred  in  the  BilaterallyDefinedBodyPart. 

It  is  recommended  that  a  1988  system  be  able  to  support  the  Undefined  Body  Part  (14),  if  it  also 
supports  Extended  Body  Parts.  This  is  in  order  to  facilitate  inter-working  with  1984  systems. 
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'Annex  E  (informative) 


Secure  Messaging  Guidelines 


E.I 


Introduction 


The  purpose  of  the  security  functional  group  Is  to  define  an  approach  to  the  provision  of  secure  messaging 
with  Message  Handling  systems  within  the  general  framework  of  these  Implementation  Agreements. 


E.2      Message  Handling  Vulnerabilities 

The  message  handling  vulnerabilities  (threats)  which  can  be  protected  using  security  measures  are  defined 
In  Annex  D  (Security  Threats)  to  Recommendation  X.402  (1988): 


b)  Message  sequencing; 

c)  Modification  of  information; 

d)  Denial  of  service; 

e)  Repudiation; 

« 

f)  Leakage  of  information. 

I  Other  specific  threats  exist  if  there  is  a  failure  to  maintain  information  separation,  which  includes: 

a)  Manipulation; 

b)  Misrouting. 

Some  of  these  threats  are  defined  in  ISO  standard  IS  7498,  OSi  Reference  Model,  Part  2:  Security 
Architecture.  The  ISO  standard  also  specifies  other  threats,  not  all  of  which  are  relevant  to  message  handling 


Annex  D  to  CCITT  Recommendation  X.402  (1988)  also  indicates  which  MHS  security  services  may  provide 
protection  against  such  threats. 

Some  threats  to  message  handling  systems  cannot  be  easily  prevented,  merely  detected,  others  are  not 
appropriated  for  standardization. 


a) 


Masquerading; 


systems. 
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E.3.1       Security  Policy 

A  general  security  policy  can  be  defined  as  tlie  set  of  laws,  rules,  and  practices  that  regulate  how  an . 
organization  manages,  protects,  and  distributes  sensitive  information.  Thus  a  security  policy  defines  an 
organization's  overall  approach  to  security  and  must  cover  all  security  aspects. 

Security  within  an  organization  is  not  only  the  concern  of  message  handling  service  and  must  be  viewed 
in  a  more  global  and  general  sense.  The  wider  aspects  of  a  security  policy  would  therefore  include 
personnel  security  (such  as  the  vesting  and  confidence  placed  in  stafO,  end-user  access  control,  physical, 
procedural  and  documentation  security.  These  Implementation  Agreements  however  is  only  concerned  with 
Electronic  Information  Security  (EIS),  specifically  in  the  areas  of  communications  (COMSEC)  and  computer 
(COMPUSEC)  as  applicable  to  standardization  of  a  secure  message  handling  system  operating  in  a  store 
and  forward  environment. 


E.3.2       Security  Classes 

In  the  X.400  (1988)  Recommendations,  some  threats  are  countered  by  EIS  measures,  these  measures  are 
realized  by  providing  security  services  and  implemented  using  security  elements. 

These  Implementation  Agreements  groups  together  security  features  of  a  message  handling  system  defined 
by  the  base  standards  into  separate  classes.  A  security  class  can  be  viewed  as  a  tool  which  can  be  used 
to  implement  a  security  policy,  and  is  not  a  security  policy  in  its  own  right  but  a  component  of  a  security 
policy. 

These  Implementation  Agreements  includes  a  set  of  security  classes;  each  class  stipulates  a  set  of 
mandatory  and  optional  security  services.  The  security  classes  are  incremental  subsets  of  the  security 
features  in  the  MHS  Base  Specifications: 

Security  Class  SO  only  requires  support  of  end-to-end  security  services  between  UAs  (content 
integrity,  message  origin  authentication,  proof  of  delivery),  and  hence  can  be  used  to  provide  some 
protection  even  in  the  case  of  transit  through  an  intermediary  MTS  which  may  not  be  trusted. 

Security  Class  S1  additionally  requires  support  and  use  of  secure  access  management  within  the 
MTS  so  as  to  allow  the  enforcement  of  a  label-based  security  policy  and  enable  trusted  interworking 
between  security  domains. 

Security  Class  S2  additionally  requires  support  and  use  of  origin  authentication  checks  within  the 
MTS  to  verify  the  origin  of  messages,  probes,  and  reports,  thereby  making  it  possible  to  provide 
non-repudiation  within  the  MTS. 

Mandatory  security  services  within  a  security  class  can  be  selected  by  the  subscriber  or  user,  either  on  a 
per-message  basis,  or  for  an  agreed  contractual  period  of  time.  It  is  a  local  issue  to  determine  when  a 
mandatory  security  service  is  offered  for  user  selection  or  when  it  is  permanently  invoked.  Facilities  and 
mechanisms  to  support  the  mandatory  security  services  must  always  be  provided  within  the  security  class, 
which  specifies  the  services  as  "mandatory". 
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E.3.3       Dynamic  Behavior  Requirements 

The  use  of  some  security  services  is  always  required  for  certain  security  classes.  This  is  specified  in  these 
Implementation  Agreements  by  imposing  additional  dynamic  requirements,  to  those  specified  in  the  base 
standards,  ensuring  that  the  corresponding  protocol  elements  are  always  present. 

Similarly,  use  of  some  security  services  are  prohibited  for  certain  security  classes.  This  is  specified  In  these 
Implementation  Agreements  by  imposing  additional  dynamic  requirements  to  those  specified  in  the  base 
standards,  ensuring  that  the  protocol  elements  are  never  present. 


E.3.4       Encryption  Techniques 

The  secure  messaging  facilities  defined  in  the  base  standards  are  provided  using  three  basic  security 
techniques,  namely: 

a)  Symmetric  encryption; 

b)  Asymmetric  encryption; 

c)  Trusted  functionality  (i.e.,  COMPUSEC  measures). 

The  base  standards  permit  the  use  of  the  techniques  on  an  Individual  basis  to  provided  security  services 
or  they  can  be  combined  in  support  of  a  security  policy.  These  Implementation  Agreements  combine  the 
techniques  in  order  to  provide  a  comprehensive  set  of  security  facilities,  which  are  intended  to  counter 
various  combinations  of  the  vulnerabilities  of  a  messaging  service.  In  some  cases  the  security  services 
defined  in  the  base  standards  can  only  be  implemented  using  one  of  the  techniques  above,  namely 
asymmetric  encryption.  However,  the  actual  technique  employed  shall  be  dependent  on  the  algorithms, 
which  shall  be  registered  by  a  security  authority  for  the  domain. 

It  is  the  intention  of  these  Implementation  Agreements  that  implementations  will  not  be  restricted  to 
asymmetric  techniques.  All  the  mandatory  security  services  can  be  implemented  using  trusted  functionality 
in  combination  with  symmetric,  asymmetric,  or  both  encryption  techniques. 

Although  the  base  standards  defines  the  syntax  of  an  asymmetric  token,  these  Implementation  Agreements 
takes  into  account  the  ISO/CCITT  MHS  Implementors'  Guide,  which  permits  the  use  of  both  asymmetric 
and  symmetric  techniques  for  both  the  signed  and  encrypted  data. 

The  actual  technique  employed  depends  on  the  algorithm  used.  Algorithms  are  assumed  to  be  bilaterally 
agreed  or  registered  by  a  registration  authority.  However,  the  algorithm-identifier  must  be  unique  and 
unambiguously  define  the  algorithm. 

It  is  recommended  that  a  conforming  ASN.1  BIT  STRING  is  normally  used  to  contain  the  encrypted  data  (as 
generated  by  use  for  the  ENCRYPTED  macro),  thereby  ensuring  insertion  of  padding  zero  bits  which  may 
be  necessary  for  correct  operation  of  certain  algorithms.  Alternatively,  the  implementation  should  take  such 
action  explicitly. 

It  is  recommended  that,  in  the  absence  of  any  requirement  for  support  of  other  specific  algorithms, 
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implementations  shall  as  a  default  support  algorithms  identified  in  CCITT  X.509  (ISO/IEC  9594-8).  It  is  also 
strongly  recommended  that  implementations  are  capable  of  using  any  encryption-based  technique  on  a 
"plug-in"  or  modular  basis. 

In  the  case  of  verification  of  SIGNATURES  (e.g.,  proof  of  delivery,  MOAC,  POAC,  or  ROAC),  implementations 
should  assume  that  all  relevant  data  present  in  the  subject  message,  probe,  or  report  has  been  included  in 
the  signature. 


E.3.5       Implementation  Considerations 
E.3.5.1         Peer  Entity  Authentication 

i 

Peer  entity  authentication  is  provided  using  the  strong  authentication  mechanisms  on  the  various  Bind 
operations,  using  either  asymmetric  or  symmetric  techniques.  The  key  management  information  necessary  « 
for  symmetric  peer  entity  authentication  is  outside  the  scope  of  these  Implementation  Agreements. 

E.3.5.2  Confidentiality 

Connection  confidentiality  is  provided  using  the  underlying  OSI  layers  and  is  outside  the  scope  of  these 
Implementation  Agreements.  Mechanisms  to  support  connection  confidentiality  are  subject  to  bilateral 
agreement  between  peers  (i.e.,  connection  confidentiality  may  even  be  achieved  by  trusting  the  connection 
to  the  peer  OSI  entity). 


Content  Confidentiality  may  be  achieved  by  either  symmetric  or  asymmetric  encryption  techniques.  It  should 
be  noted  that  use  of  asymmetric  techniques  precludes  submission  of  messages  to  multiple  recipients. 


E.3.5.3  Integrity 


Connection  Integrity  is  provided  using  the  underlying  OSI  layers  and  is  outside  the  scope  of  these 
Implementation  Agreements.  Mechanisms  to  support  Connection  Integrity  are  subject  to  bilateral  agreement 
between  peers.  It  should  be  noted  that  the  integrity  of  a  connection  can  be  increased  by  use  of  RTSE. 


Content  Integrity  is  achieved  by  computing  a  content  integrity  check  as  a  function  of  the  entire  message 
content.  When  symmetric  techniques  are  used  to  compute  the  content  integrity  check  a  secret  key  is  ^ 
required.  This  content  integrity  key  may  be  confidentially  sent  to  the  message  recipient  using  the  message  ' 
argument  confidentiality  security  element  in  the  message  token  (i.e.,  there  may  be  other  keys  or  parts  of  the  ■ 
key  not  sent  by  the  originator  with  the  message,  but  the  key  management  of  such  external  keys  is  outside  ■ 
the  scope  of  these  Implementation  Agreements).  It  should  be  noted  that  placing  the  content  integrity  check 
in  the  encrypted  data  of  the  message  token  will  provide  additional  protection  against  masquerade  threats. 

NOTE  -  Content  Integrity  can  also  provide  integrity  of  receipt  and  non-receipt  notifications  (IPNs)  and  can 
assist  in  the  provision  of  "non-repudiation  of  receipt"  since  non-repudiation  of  delivery  may  be  insufficient  where 
delivery  is  to  a  Message  Store. 

I 

I 
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E.3.5.4 


Message  Origin  Authentication 


End-to-end  (i.e.,  UA  to  UA)  Message  Origin  Autlientication  is  automaticaily  provided  by  content  integrity. 
Security  classes  S2  and  S2a  provide  additional  protection  (i.e.,  of  the  integrity  of  the  label)  by  requiring 
support  of  origin  authentication  checks  within  the  MTS. 


If  asymmetric  techniques  are  used  for  content  integrity  it  can  also  provide  non-repudiation  of  origin  (UA 
to  UA)  depending  on  the  level  of  trust  placed  In  the  certificate.  If  symmetric  techniques  are  used,  content 
integrity  can  also  provide  non-repudiation  of  origin,  but  only  by  using  a  trusted  notary  to  validate  the 
content  integrity  and  provide  trusted  key  management  facilities.  A  degree  of  non-repudiation  can  be 
provided  by  the  use  of  trusted  accountability  services. 

NOTE  -  It  is  assumed  that  an  originating  UA  will  ensure  that  delivery  notification  is  requested  when  proof 
of  delivery  is  requested. 


E.3.5.6        Secure  Access  Management 

Secure  Access  Management  can  be  implemented  by  a  combination  of  Multi-Level  Security  (MLS) 
functionality  by  assurance  of  the  various  MHS  components  to  support  such  functionality.  MLS 
functionality  is  supported  in  the  base  standards  by  the  use  of  security  labels,  security  context  and  the 
security  token  and  can  be  applied  in  a  hierarchical  and/or  role  manner  depending  on  the  policy 
requirements  of  a  domain. 

MLS  assurance  will  generally  also  require  other  (COMPUSEC)  measures  and  is  outside  the  scope  of  the 
base  standards  and  these  Implementation  Agreements.  Reference  should  be  made  to  the  appropriate 
security  authority  and  any  applicable  security  evaluation  criteria  (e.g.,  U.  S.  DoD  Orange  Book,  UK  - 
Netherlands  -  Germany  -  France  draft  Evaluation  Criteria). 


E.3.5.7        Implications  for  the  Use  of  Distribution  Lists 

An  MTA  performing  distribution  list  expansion  must  create  all  the  per-recipients  fields  for  the  members  of 
the  distribution  list.  It  may  either  generate  a  new  token  for  each  DL  member  (i.e.,  using  the  recipient 
name  of  that  DL  member)  or  alternatively  it  may  copy  the  same  token  (i.e.,  containing  the  recipient  name 
of  the  DL  itself)  into  the  per-recipient  fields  for  each  DL  member.  In  the  former  case,  the  content- 
integrity-check  should  not  be  changed  if  it  is  to  be  used  to  provide  message  origin  authentication.  Also 
in  such  case,  the  DL  expansion  point  must  have  at  least  the  same  security  class  as  the  originator  and 
must  have  trusted  functionality.  The  choice  of  which  approach  to  use  will  therefore  need  to  be 
determined  in  accordance  with  the  security  policy  which  may  prohibit  the  use  of  distribution  lists 
altogether. 


E.3.5.5 


Non-Repudiation 


105 


Part  8:  1988  Message  Handling  Systems 


December  1990  (Stable) 


E.3.5.8 


Implications  on  Redirection 


The  Security  Functional  Group  has  the  effect  of  either  requiring  trust  in  any  redirection  facilities  or  | 
prohibiting  the  use  of  redirection.  If  the  Redirection  facility  is  to  be  trusted,  it  must  be  subject  to  the 
security  policy  and  obey  the  security  labels  as  defined  in  the  base  standards.  It  is  recommended  that  the  I 
token  is  not  altered  on  redirection  (i.e.,  it  will  contain  the  originally-specified  recipient  name). 


Interworking  between  implementations  conforming  to  Security  Functional  Groups  and  1984  systems  is 
not  supported.  The  Double  Enveloping  technique  can  be  used  to  traverse  an  1984  system. 


E.3.5.10       Implications  for  Use  of  Directory 

The  X.400  security  services  use  of  the  directory  service  does  not  require  a  trusted  directory  because  the 
information  that  is  retrieved  is  certified  and  can  be  validated  independently  of  the  directory. 

Other  threats  (e.g.,  malicious  corruption  of  directory  information)  may  arise  from  the  broader  use  of  the 
directory,  however  these  are  outside  of  the  scope  of  the  X.400  base  standard  and  this  Implementors 
Agreement. 

Work  continues  within  CCITT  and  ISO  to  improve  the  security  inherent  in  the  Directory  standards. 


E.3.5.1 1       Implications  for  Conversion 

Implementation  of  the  Security  functional  group  may  additionally  either  require  that  any  conversion 
facilities  are  highly  trusted  to  regenerate  the  appropriate  security  elements  (notably  the  content  integrity 
check)  or  prohibit  the  use  of  conversion  within  the  MTS  altogether.  In  particular,  it  should  be  noted  that 
use  of  conversion  facilities  will  invalidate  any  origin  authentication  based  on  the  original  content. 


E.3.5.1 2  Accountability 

Accountability  depends  on  the  identification  and  authentication  of  users,  then  subsequent  records  being 
kept  on  the  actions  taken  by  users.  Therefore,  accountability  depends  on  all  the  relevant  information 
being  properly  stored  or  recorded. 

Accountability  features  provided  by  domains  (or  MTAs)  are  subject  to  bilateral  agreement  between 
domains  (or  MTAs)  and  may  optionally  provide  non-repudiation  services.  Accountability  features  include 
pervasive  mechanisms  such  as  security  logs,  audit  trails  and  archives,  or  they  may  be  mechanisms 
supported  by  protocol.  Protocols  to  support  accountability  will  be  subject  to  bilateral  agreement. 


E.3.5.9 


Implications  for  1984  Interworking 
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E.3.5.13       Double  Enveloping 

Double  enveloping  can  be  used  with  each  secure  messaging  security  class.  For  each  security  class  it  is 
an  optional  extension  to  the  security  features  which  can  be  used  to  counter  specific  vulnerabilities.  When 
double  enveloping  is  used,  it  shall  be  applied  at  the  boundary  of  a  domain,  and  obey  the  rules  of  an 
MTA  at  management  domain  boundaries.  Figure  20  Illustrates  the  technique. 


Outer  Envelope  2 


Content  2 


Inner  Envelope  1 

Content  1 

Figure  20  -  Double  Enveloping  Technique. 

Address  information  in  envelope  1  and  2  are  not  necessarily  the  same. 
Trace  information  in  envelope  1  and  2  are  not  necessarily  the  same. 

The  double  envelope  technique  can  be  used  in  1984  and  1988  MTS  environments.  When  used  in  an 
1988  environment,  any  security  class  can  be  applied  to  the  outer  envelope.  It  is  recommended  that  the 
inner  envelope  is  encrypted.  When  the  double  envelope  technique  is  used  as  a  secure  relay  path  via  an 
1984  domain,  any  encryption  of  the  content  2  is  subject  to  bilateral  agreement. 

Trace  information  is  not  passed  between  inner  and  outer  envelopes.  It  is  recommended  that  trace 
information  on  the  outer  envelope  is  always  archived  when  the  double  envelope  technique  is  used. 


E.4     Security  Class  SO 


E.4.1  Rationale 

Security  class  SO  is  confined  to  security  functionality  operating  between  MTS-Users  on  an  end-to-end 
basis.  It  is  designed  to  minimiz:;  the  required  functionality  in  the  MTS  to  support  submission  of  elements 
associated  with  these  services.  Security  services  which  must  be  supported  (i.e.,  must  be  made  available) 
are  those  which  are  considered  in  any  secure  messaging  environment,  i.e.: 

a)  Content  Integrity; 
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b)  Message  Origin  Authentication  (end-to-end); 

c)  Proof  of  Delivery. 

Other  security  services,  such  as  Content  Confidentiality,  rnay  optionally  be  supported. 


E.4.2       Technical  Implications 

The  technical  Implications  for  security  class  SO  are: 

a)  It  is  necessary  to  provide  mechanisms  in  a  UA  which  can  generate  the  signed,  signature  and 
encrypted  macros  on  message  submission; 

b)  It  Is  necessary  to  provide  mechanisms  in  a  UA  which  can  handle  the  signed,  signature  and 
encrypted  macros  on  message  delivery. 


E.5     Security  Class  SI 


E.5.1  Rationale 

The  S1  security  class  is  a  superset  of  security  class  SO  and  introduces  the  basic  requirement  for  security 
functionality  not  only  within  the  MTS-User  but  also  within  the  MTS.  This  security  functionality  within  the 
IVITS  is  designed  to  support  the  enforcement  of  a  security  policy  within  a  security  domain.  As  a 
consequence,  S1  enables  trusted  routing  to  be  implemented. 

NOTE  -  The  level  of  trust  in  the  route  will  depend  on  the  level  of  trust  in  the  security  label  and  security 
context. 


E.5.2       Technical  Implications 

The  technical  implications  of  security  class  S1  are: 

a)  It  is  necessary  to  provide  mechanisms  in  a  UA  which  can  generate  the  signed,  signature  and 
encrypted  macros  on  message  submission. 

b)  It  is  necessary  to  provide  mechanisms  in  a  UA  which  can  handle  the  signed,  signature  and 
encrypted  macros  on  message  delivery. 

c)  It  is  necessary  to  provide  mechanisms  In  the  MTA  for  registration,  change-credentials  and 
bind  abstract  operations  (i.e.,  signed  macro  for  bind). 

d)  It  is  necessary  to  provide  mechanisms  In  the  MS  for  MS-registration  and  MS-bind  operation 
(i.e.,  signed  macro  for  MS-Bind). 
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e)  It  is  necessary  to  support  message  security  labelling  (the  level  of  assurance  is  subject  to 
Individual  security  domain  requirements). 

f)  It  is  necessary  that  reliable  access  is  always  supported. 

g)  It  is  necessary  for  the  MTAs  to  check  the  existence  of  the  security  elements  which  are 
classified  as  "dynamic  mandatory". 

h)  It  is  necessary  to  provide  a  trusted  connection  between  peers  to  provide  adequate 
confidentiality,  integrity  and  peer  entity  authentication. 


iE.6     Security  Class  82 


E.6.1  Rationale 

Security  Class  S2  is  a  superset  of  Security  Class  Si.  It  enhances  the  facilities  of  the  MTAs  in  order  to 
check  the  origination  of  messages,  probes,  and  reports  within  the  MTS  and  to  provide  enhanced 
integrity  checks  on  the  security  label  while  in  the  MTS.  The  extra  security  services  provided  by  this 
security  class  can  help  to  provide  trusted  routing  within  an  MTS. 

Additionally,  It  is  possible  to  provide  non-repudiation  within  an  MTS. 


E.6.2       Technical  Implications 

The  extra  security  services  specified  by  Security  Class  S2  use  asymmetric  techniques  exclusively. 
The  technical  implications  are  as  in  Security  Class  S1 ,  plus: 

a)  It  Is  necessary  to  provide  mechanisms  in  an  MTA  and  UA  that  can  process  the  signed  macro 
of  certificates; 

b)  The  constraint  that  the  option  of  supporting  Content  Confidentiality  cannot  be  allowed  when 
the  message  origin  authentication  check  (MOAC)  is  used  to  provide  non-repudiation  services. 
Under  this  condition  Content  Confidentiality  is  not  supported.  If  the  MOAC  is  not  used  for  this 
purpose,  Content  Confidentiality  can  be  supported  as  an  optional  security  service; 

c)  It  is  necessary  to  provide  mechanisms  in  a  MTA  which  can  generate  and  process  the 
signature  macro  of  a  message,  probe,  and  report  authentication  check  (MOAC,  POAC  and 
ROAC); 

d)  It  is  necessary  to  provide  mechanisms  in  a  UA  and  MTA  that  can  interface  with  an  X.500 
directory  supporting  the  Authentication  Framework  as  defined  in  X.509/ISO  9594-8  or  can 
distrubute  public  keys  by  other  trusted  means  which  is  compliant  with  X.509; 

e)  It  is  necessary  to  provide  a  trusted  means  of  generating  certificates; 
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f)  It  is  necessary  to  provide  mechanisms  in  tlie  MTA  wfiich  can  process  a  proof  of  submission 
request  and  generate  tlie  proof  of  submission  signature; 

g)  It  is  necessary  to  provide  a  mechanism  in  an  MTA  which  will  generate  ROAC  signatures  with 
reports; 

h)  Connection  confidentiality  is  only  provided  by  this  security  class  when  the  message-origin- 
authentication-check  is  computed  using  clear  content  to  provide  non-repudiation  of  origin 
security  service  (i.e.,  non-repudiation  is  provided  only  on  the  clear  content  of  the  message); 

i)  The  irrevocable  proof  required  to  provide  non-repudiation  within  the  MTS  is  achieved  by  the 
management  of  asymmetric  keys.  The  explicit  definition  of  asymmetric  key  management  is 
outside  the  scope  of  these  Implementors  Agreements. 


E.7     Confidential  Security  Class  Variants  (SOa,  S1a,  and  S2a) 


E.7.1  Rationale 

These  security  class  variants  are  supersets  of  SO,  S1 ,  and  S2,  adding  the  requirement  for  support  of 
end-to-end  content  confidentiality.  The  rationale  for  these  variants  is  to  avoid  the  implementation  cost 
and  processing  overhead  involved  in  encrypting  the  entire  message  content  unless  there  is  a  definite 
requirement.  It  is  also  possible  to  protect  the  encryption  techniques  and  mechanisms  (i.e.,  algorithms, 
key  lengths,  key  versions,  etc.)  by  Secure  Access  Management. 


E.7.2       Technical  Implications 

The  technical  implications  of  the  confidential  security  class  variants  are  the  same  as  those  for  the 
corresponding  primary  security  class,  plus: 

a)  It  is  necessary  to  provide  mechanisms  in  a  UA  which  can  use  the  encrypted  macros  to 
encrypt  and  decrypt  the  message  content. 
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Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  File  Transfer,  Access  and 
Management  Special  Interest  Group  (FTAM  SIG)  of  the  National  Institute  of  Standards  and  Technology 
(NIST)  Workshop  for  Implementors  of  Open  Systems  Interconnection  (OSI).  See  Procedures  Manual  for 
Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part 
replaces  the  previously  existing  chapter  on  this  subject.  There  is  no  significant  technical  change 
from  this  text  as  previously  given. 


ix 


I 


Part  9  -  ISO  File  Transfer,  Access  and  Management  Phase  2 


NOTE  -  In  document  type  names,  constraint  set  names,  and  abstract  syntax  definitions,  the  "NBS"  designation 
will  be  preserved. 


0  Introduction 

This  part  defines  Implementors'  Agreements  based  on  ISO  File  Transfer,  Access  and  Management  (FTAM), 
as  defined  in  ISO  8571 .  This  International  Standard  has  four  parts.  Part  1  of  the  IS  gives  general  concepts, 
part  2  defines  the  Virtual  Filestore  (VFS),  part  3  defines  the  File  Service,  and  part  4  defines  the  File  Protocol. 

FTAM,  as  described  in  the  IS,  is  based  on  the  following  ISO  documents:  ACSE  Service  and  Protocol  (ISO 
8649,  ISO  8650),  Presentation  Service  and  Protocol  (ISO  8822,  ISO  8823),  ASN.1  Abstract  Syntax  Notation 
and  Basic  Encoding  Rules  (ISO  8824,  ISO  8825),  and  Session  Service  and  Protocol  (ISO  8326,  ISO  8327). 
These  services  and  protocols  are  defined  architecturally  in  the  OSI  Reference  Model  (ISO  7498).  These 
Agreements  provide  detailed  guidance  for  the  implementor,  and  eliminate  ambiguities  in  interpretations. 

The  general  agreements  reached  with  respect  to  the  ISO  File  Transfer,  Access  and  Management  Protocol 
(FTAM)  are  that  the  Phase  2  FTAM  specification  (this  part)  is  based  on  the  International  Standard  (IS). 


1  Scope 

These  FTAM  Phase  2  Agreements  cover  transfer  of  and  access  to  files  between  the  Filestores  of  two  end 
systems,  including  the  management  of  a  Virtual  Filestore.  One  end  system  acts  in  the  Initiator  role  and 
initiates  the  file  transfer/access,  while  the  other  end  system  acts  in  the  Responder  role  and  provides  access 
to  the  file  in  the  Virtual  Filestore.  This  part  describes  Agreements  for  the  actions  and  attributes  of  the  Virtual 
Filestore,  and  the  service  provided  by  the  file  service  provider  to  file  service  users,  together  with  the 
necessary  communications  between  the  Initiator  and  Responder. 


virtual 
Fi lestore 
2 


Real 
Fi lestore 
1 

Etxl 
System  1 
-  Initiator  - 

End 
System  2 
-  Responder  - 

Real 
Fi lestore 
2 

Figure  1  -  Model  of  file  transfer/access. 


NOTE  -  Agreements  apply  on  the  double  lines  of  figure  1 .  The  mapping  between  the  Virtual  Filestore  and 
the  Real  Filestore  together  with  the  local  data  management  system  is  not  part  of  these  Agreements. 


These  Agreements  define  general  Agreements  in  clauses  5  through  16,  minimum  functionality  (Conformant 
Implementations)  in  clause  17,  and  functionality  for  several  Implementation  Profiles  which  are  tailored  to 
different  classes  of  user  requirements  in  clauses  18  and  19. 
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2     Normative  References 

ISO  8571-1:  1988(E),  Information  Processing  Systenns  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  f^anagement  Part  1:  General  Introduction 

8571-2:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer, 
Access  and  Management  Part  2:  Virtual  Filestore  Definition  ISO 

ISO  8571-3:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  3:  The  File  Service  Definition 

ISO  8571-4:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  4:  The  File  Protocol  Specification 


Version  3  of  the  FTAM  Phase  2  Implementation  Agreements  was  completed  December  15,  1989,  and 
published  in  version  3  of  the  Stable  Implementation  Agreements  (NIST  Special  Publication  500-177, 
December  1989).  Some  editorial  clarifications  and  technical  changes  (due  to  international  harmonization 
of  Profiles)  were  added  to  Version  3  Agreements  in  the  course  of  1990.  All  these  changes  are  now  fully 
incorporated  in  this  version  4  of  the  FTAM  Phase  2  Stable  Agreements. 

No  further  enhancements  will  be  made  to  this  version  4  of  FTAM  Phase  2  (see  the  clause  4  ERRATA). 

This  version  4  of  the  FTAM  Phase  2  Agreements  fully  replaces  the  version  3  as  published  in  NIST  SP  500- 
1 77.  Therefore,  the  old  version  3  of  FTAM  Phase  2  will  no  longer  be  maintained. 

The  following  list  summarizes  the  technical  errata  changes  to  FTAM  Phase  2,  Version  1  which  were 
incorporated  in  Version  2.  It  also  states  the  degree  of  possible  interworking  and  t)ackward  compatibility  to 
RAM  Phase  2,  Version  1 . 
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Technical  Changes  In  FTAM  Phase  2, 
Version  2  (Dec.  '88) 

Backward  Compatibility  to  FTAM 
Phase  2,  Version  1  (Dec.  '87) 

1 .  Check  of  already  established 
presentation  contexts  for  a 
document  type  not  at  CREATE 
time  but  at  OPEN  time 

Interworking  problems  could  occur 
when  creating  a  document  type 
which  is  not  opened 

2.  Receivers  shall  not  require 
sending  of  AETtitles 

Interworking  problems  could  occur 
if  AETitles  are  not  sent 

3.  Minimum  requirement  for  FADU 
identities  for  document  types 
which  use  the  sequential  flat 
constraint  set 

Interworking  problems  could  occur 
if  FADU  identities  beyond  the 
minimum  requirement  are  used 
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The  following  list  summarizes  the  technical  errata  and  alignment  changes  which  were  incorporated  in  FTAM 
Phase  2,  Version  3.  It  also  states  the  degree  of  possible  interworking  and  backward  compatibility  to  FTAM 
Phase  2,  Version  2. 


Technical  Changes  in  FTAM  Phase  2, 

Backward  Compatibility  to  FTAM 

1 .  Unconstrained  Service  Class  outside 
the  scope  of  the  Implementation 
Profiles 

Full  compatibility,  since  change  only 
from  "optional"  "to  "outside  scope" 

2.  <  contents-type-list  >  parameter: 
Both  types  of  values  optional 
for  Initiators 

Full  compatibility,  since  this 
clarification  is  only  for  Initiators 

3.  Specification  of  supported  values  for 
<  override  >  oarameter  in  F-CREATE 

Interworking  problems  may  occur,  if 
different  values  suooorted 

4.  Parameters  <filesize>,  <  future 
filesize>,  <fadu-number>  may  be 
encoded  with  up  to  8  contents 
octets 

Interworking  problems  may  occur, 
since  no  minimum  requirement  was 
defined  for  Version  2. 

5.  For  NBS-7  and  NBS-8  in 
conjunction  with  T  or  TIVI 
Service  Class,  the  FADU 
identities  "current",  "next", 
"previous"  are  not  required 

Full  compatibility,  since  these 
identities  were  never  useful  in 
conjunction  with  T  or  TM  Service 
Class 

6.  For  NBS-8  files  the  minimum  range 
for  keys  of  string-type  is  (1-16) 
instead  of  (0-16) 

Interworking  problems  may  occur 
for  key-length  parameter  0 

7.  Restriction  "NBS-9  files  may  not  be 
Created  or  Deleted"  removed  from 
the  document  type  definition.  But 
both  actions  are  outside  the  scope  of 
the  Agreements. 

Full  compatibility,  since  Creation, 
Deletion  was  never  in  the  scope  of 
the  Agreements 

8.  Constraint  set  NBS-ordered-flat: 
The  location  after  an  Insert  Is  "end" 

Full  compatibility,  since  this 
specification  was  already  implicitly 
clear 
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,4  Errata 


NU.  Ur 
ERRATA 

TVDC 
1  Yrt 

ncrcricNUcLl 
DOCUMENT 

Ol  Al  ICC 

CP  3/91-1 

EDITORIAL 

NIST-SP  500-183 

All 

Update  to  ISO  style. 
General  formatting  and 
error  corrections. 
Alignment  with  the 
wording  of  the  ISP. 
Consistent  naming 
conventions. 

liiilllll 

liliilil 

Table  9 

Datatypel  ASN.1 

Tabl$  tg 

comment  to  use  the 

miiiii 

Table  11 

object  descriptor 

miiiiiii 

Clause  17 

Annex  A 

include  Corrigenda 
Editors  rK)te  to  point  at 

iiiiii 

ISP  for  regfetered 

objectsi 

A.6>11J 

Change  header  to 
Structural  Simplification. 

CP  9/91-6 

A.7.9.1 
AJ.a2 

Added  deflnltfofis  f<» 
Datatypes 

I  5  Assumptions 

I  RAM  protocol  machines  must  be  able  to  parse  and  process  at  a  minimum  7K  octets  of  FTAM  PCI,  FTAM 
(  structuring  (FTAM-FADU)  and  FTAM  user  data  (including  grouped  FPDUs)  as  they  would  be  encoded  with 

the  ASN.1  Basic  Encoding  Rules.  It  is  recommended,  however,  that  Presentation  user  data  not  be  restricted 

in  size. 

j  In  order  to  maximize  interoperability,  it  is  important  that  the  implementations  of  FTAM  service  providers  do 
not  unnecessarily  restrict  the  service  user's  ability  to  generate  arbitrary  file  service  requests.  Otherwise,  they 
may  not  be  able  to  work  with  FTAM  Responders  whose  operation  is  constrained  by  their  mapping  of  the 
FTAM  Virtual  Filestore  to  their  local  filestore.  For  example,  error  procedures  should  only  be  invoked  when 
an  error  actually  occurs,  not  at  the  point  of  the  specification  of  options  which  might  result  in  an  error. 

^  Implementations  must  be  able  to  parse  all  valid  optional  parameters  if  they  are  present  in  the  PDU.  Only 
those  optional  parameters  specified  as  supported  in  these  Agreements  are  required  to  be  implemented.  If 
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these  parameters  are  not  present,  a  default  value  is  assigned  locally.  A  Responder  sliould  not  refuse  a 
request  solely  because  a  parameter  that  is  optional  in  the  FTAM  standard,  but  is  supported  in  these 
Agreements,  is  not  present. 

Consideration  of  any  standardized  service  interface  is  not  covered  by  these  Agreements. 

These  Agreements  define  no  restrictions  for  the  values  used  for  the  < communication  quality  of  service> 
parameter  in  <F-INITIALIZE>. 

FTAM  is  defined  in  phases.  The  Phase  1  FTAM  implementation  specification  is  based  on  the  second  ISO  H 
Draft  Proposal,  dated  April  1985,  and  the  ISO  Draft  Proposal  8824  and  8825. 

The  Phase  2  FTAM  specification  (this  part)  is  based  on  the  International  Standard  (IS).  THERE  IS  NO 
BACKWARD  COMPATIBILITY  WITH  NIST  FTAM  PHASE  1.  Backward  compatibility  is  impossible,  since 
Phase  1  uses  Session  services  directly,  while  Phase  2  uses  ACSE  and  Presentation  services.  Furthermore, 
there  are  differences  in  Filestore,  PDU  Abstract  Syntax,  FADU  Abstract  Syntax,  and  Transfer  Syntax.  There 
also  are  differences  in  the  transparency  mechanisms  and  service  class  negotiations. 

The  <  implementation  information  >  parameter  of  <F-INITIALIZE>  FPDU  as  defined  in  ISO  8571-4,  20.3  is 
used  to  pass  'user  version'  information  with  respect  to  different  FTAM  phases  of  the  NIST  Implementors 
Agreements  or  with  respect  to  FTAM  profiles  of  other  bodies  (see  clause  12).  It  is  the  goal  of  these 
Agreements  to  use  the  'user  version'  mechanism  to  provide  at  least  one  level  of  backward  compatibility  for 
all  future  NIST  FTAM  Phases,  facilitating  backward  compatibility  for  future  FTAM  products,  assuming 
different  new  versions  of  the  respective  IS's  also  enable  backward  compatibility. 

The  FTAM  specific  ASE  requirements  for  ACSE  in  the  Upper  Layers  part  of  this  document  define  a  value 
(that  carries  no  semantics)  for  the  AETitle  that  can  be  used  by  FTAM  ASEs  for  communication.  Other  values 
for  the  AETitle  are  outside  the  scope  of  these  Agreements. 

The  association  shall  not  be  rejected /aborted  if  any  of  the  following  parameters  either  contains  the  defined 
value  or  is  not  sent: 

Called  -  AETitle 
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Calling  -  AETItle 
Responding  -  AETitle 

The  association  may  be  rejected/aborted  if  any  of  these  parameters  contain  other  values. 

Use  of  values  outside  the  scope  of  these  Agreements  is  discouraged  until  agreed  upon  semantics  have  been 
associated  with  AETitles. 

Use  of  <  shared  ASE  information  >  parameter  and  <  charging  >  parameter  is  not  defined  v*/ithin  the  scope 
of  the  Agreements. 

Use  of  < application  context  name>  parameter  is  not  defined  within  the  scope  of  these  Agreements.  This 
parameter  does  not  prohibit  the  establishment  of  an  FTAM  association. 

These  Agreement  use  the  term  'supported'  for  a  parameter  to  mean  that  the  syntax  and  semantics  of  that 
parameter  shall  be  implemented.  However,  it  is  not  a  requirement  that  the  parameter  be  used  in  all 
instances  of  communication,  unless  stated  otherwise. 

Also  these  Agreements  use  the  term  'optionally  supported'  for  a  parameter  to  mean  that  it  is  left  to  the 
implementation  whether  the  semantics  of  that  parameter  are  implemented  or  not. 

6     Presentation  agreements 

The  following  Abstract  Syntaxes  are  recognized  in  these  Agreements: 
"FTAM  FADU" 
"FTAM  PCI" 

"FTAM  unstructured  text  abstract  syntax" 

"FTAM  unstructured  binary  abstract  syntax" 

"NBS  abstract  syntax  ASl" 

"NBS  file  directory  entry  abstract  syntax" 
The  following  Transfer  Syntax  is  supported: 

"Basic  Encoding  of  a  single  ASN.1  type" 
See  also  annex  C. 
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7  Service  class  agreements 

Implementation  Agreements  have  been  reached  for  the  following  service  classes: 
File  Transfer 
File  Access 
File  Management 
File  Transfer  and  Management 
Unconstrained 

8  Functional  unit  agreements 

Implementation  Agreements  have  been  reached  for  the  following  functional  units: 
Kernel 
Read 
Write 

File  Access 

Limited  File  Management 
Enhanced  File  Management 
Grouping 

Implementation  of  the  Recovery,  Restart  Data  Transfer,  and  FADU  Locking  functional  units  is  not  specified. 
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9    File  attribute  agreements 

!  Implementation  of  the  Kernel  Group  of  file  attributes  is  defined.  If  the  optional  Storage  Group  and  Security 
Group  are  implemented,  aspects  of  their  implementation  are  defined.  Implementation  of  the  Private  Group 
is  not  specified. 

Responses  to  an  attribute  value  request  shall  always  include  one  of  the  following  (as  specified  in  ISO  8571  -2, 
i  clause  4): 

An  actual  file  attribute  value. 

A  value  indicating  that  no  value  is  available,  optionally  with  a  diagnostic. 

No  value  and  an  error  code,  optionally  with  a  diagnostic  indicating  that  the  attribute  is  not 
supported. 


9.1      Mandatory  group 

Only  the  Kernel  Group  of  attributes  is  required.  A  value  for  <filename>,  < permitted  actions>,  and 
<  contents  type>  will  always  be  available. 

A  minimum  range  is  required  for  <filename>  values  as  specified  in  ISO  8571-2.  No  maximum  length  or 
format  restrictions  apply.  A  system  that  does  not  support  < filename >  values  with  a  sequence  of  more  than 
one  Graphic  String  or  extended  <filename>  characteristics  may  reject  a  request  involving  such  a 
<filename>.  All  systems  must  be  able  to  interpret  a  < filename  >  value  with  a  sequence  of  one  Graphic 
String. 

A  Responder  shall  not  require  an  Initiator  to  use  multiple  component  Graphic  String  filenames.  Requests 
using  a  single  component  < filename >  value  with  a  sequence  of  one  Graphic  String  shall  be  responded  to 
using  a  single  component  <filename>  value.  Responses  to  requests  involving  < filename >  values  having 
two  or  more  Graphic  Strings  are  not  defined  here  but  may  be  interpreted  via  bilateral  or  other  external 
agreements.  Use  of  < filename >  values  with  a  sequence  of  more  than  one  Graphic  String  is  discouraged. 

Apart  from  the  minimum  conformance  requirements  specified  in  ISO  8571-2,  file  names  have  to  be  specified 
in  the  naming  convention  of  the  responding  FTAM  implementation.  It  is  a  local  implementation  matter  of 
the  FTAM  Responder,  whether  or  not  an  additional  name  mapping  onto  the  real  Filestore's  file  name 
convention  is  supported. 

In  order  to  enable  interworking  with  all  FTAM  Responders'  virtual  Filestores,  it  is  recommended  that  FTAM 
Initiators  impose  no  restrictions  on  the  attribute  range  supported  for  file  names  beyond  those  specified  in 
ISO  8571-2. 

For  the  purpose  of  intenworking  according  to  these  Agreements  the  <  contents  type>  attribute  is  limited  to 
the  <documenttype  name>  format.  The  <  constraint  set  name,  abstract  syntax  name>  form  is  outside  the 
scope  of  these  Agreements.  It  should  always  be  parsed  correctly  when  received,  but  may  result  in  an  error. 
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9.2      Optional  groups 

If  the  optional  Security  Group  of  file  attributes  is  implemented,  an  actual  value  must  be  available  for  the 
<  access  control  >  attribute. 

The  <  access  control  >  attribute  is  a  SET  OF  < access  control  element  >.  The  minimum  requirement  in  these  > 
Agreements  is  the  support  of  one  <access  control  element>,  according  to  the  base  standard.  The  terms 
< concurrency  access >,  < identity >,  and  < passwords >  are  each  optionally  supported.  Details  of  their  use  i 
shall  be  specified  in  the  PICS.  Use  of  the  <  location  >  term  is  not  specified  in  these  Agreements. 

Implementation  of  the  Private  Group  is  not  specified. 

10   Document  type  agreements 

These  document  types  are  defined: 


FTAM-1 

"ISO  FTAM  unstructured  text" 

FTAM-2 

"ISO  FTAM  sequential  text" 

FTAM-3 

"ISO  FTAM  unstructured  binary' 

NBS-6 

"NBS-6 

FTAM  sequential  file" 

NBS-7 

"NBS-7 

FTAM  random  access  file" 

NBS-8 

"NBS-8 

FTAM  indexed  file" 

NBS-9 

"NBS-9 

FTAM  file  directory  file" 

Detailed  document  type  definitions  are  given  in  annex  A  and  in  ISO  8571-2,  annex  B. 

NOTE  -  Document  types  NBS-1  to  NBS-5  are  not  defined  in  these  Agreements.  The  numbering  starts  with 
NBS-6  because  of  the  original  DiS  version  of  these  Agreements. 

An  implementation  claiming  conformance  to  these  Agreements  which  also  supports  any  or  all  of  the 
document  types  FTAM-1,  FTAM-2,  and  FTAM-3  as  defined  in  ISO  8571-2,  annex  B,  must  minimally  support 
the  combinations  of  parameter  values  as  specified  in  table  1 


March  1991  (Stable) 
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jtable  1  -  Parameters  for  FTAM-1,  -2,  -3 


r~  

Class  Number 

Maximum 
String  Length**' 

Strina 

wLI  II IM 

Significance 

FTAM-1 

General  String  '(27) 
lASString  '(22) 

134  or  less 

'not-significant'® 

FTAM-2 

Graphic  String  ''(25) 

134  or  less^ 

'not-significant'® 

FTAM-3 

<not  applicable  > 

512  or  less 

'not-significant"' 

NOTES 


1  The  minimum  level  of  support  for  General  String  is  the  ISO  646,  IRV  GO  character  set  and  the  8859-1  GO 
and  G1  character  sets,  and  ISO  646,  IRV  CO  set. 

2  The  support  for  IA5  String  is  the  ISO  646,  IRV  GO  character  set  and  the  ISO  646,  IRV  CO  set. 

3  The  minimum  level  of  support  for  Graphic  String  is  the  ISO  646,  IRV  GO  character  set  and  the  8859-1  GO 
and  G1  sets. 

4  This  is  the  default  when  the  parameter  is  not  specified. 

5  The  implementation  need  not  support  Data  Units  whose  total  character  count  exceeds  134. 

6  As  per  table  3. 

7  The  length  refers  to  the  number  of  characters  from  the  applicable  character  set.  It  does  not  include  any 
escape  sequences  or  overhead  from  the  encoding. 

8  If  escape  sequences  are  used  in  the  encoding  of  the  data  and  string  boundaries  are  not  maintained  when 
the  file  is  stored,  it  may  be  necessary  for  the  escape  sequences  to  occur  at  different  locations  when  the  file 
is  re-sent. 

For  document  types  which  use  the  sequential  flat  constraint  set,  conformant  implementations  must 
minimally  support  FADU  identities  as  follows: 

-  for  Transfer  service  class:  'begin',  'end' 

-  for  Transfer  and  Management  service  class:      'begin',  'end' 

-  for  Access  service  class:  'begin',  'end',  'first',  'next' 

For  the  document  types  NBS-7  and  NBS-8  used  in  conjunction  with  the  Transfer  service  class  or  the 
Transfer  and  Management  service  class,  the  support  of  the  FADU  identities  of  'current',  'next'  and  'previous' 
and  for  NBS-8  the  support  of  the  FADU  identity  of  'end'  are  outside  the  scope  of  these  Agreements. 

For  the  document  types  NBS-6,  NBS-7  and  NBS-8  parameters  are  used  for  which  the  Agreements  apply  as 
specified  in  table  2. 
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Table  2  -  Parameters  for  NBS-6,  NBS-7,  NBS-8 


Parameter 

Prim  Type 

String-length 

Length-1 

Length-2 

int 

INTEGER 

Number  of  octets 
required  to 
represent,  in  2's 
complement 
format,  the  largest 
integer  to  be 
passed 

bit 

BIT  STRING 

Number  of  bits  in 
string  (non-varying) 

ia5 

IA5STRING 

Max  number  of 
characters  in  string 

graphic 

Graphic  String 

Max  number  of 
characters  in  string 

general 

General  String 

Max  number  of 
characters  in  string 

octet 

OCTET 
STRING 

Max  number  of 
octets  in  string 

private- 
class- 
numDer 

Floating  Point 
Number 

The  minimum 
number  of  bits 
recjuirea  lo  oe 
maintained  in  the 
mantissa  for 
relative  precision 

Number  of  bits 
required  to 
represent  ine 
largest 
unbiased 
integer 

exponent  in  2's 
complement 

univer-time 

UTCTime 

<not  applicable  > 

gen-time 

Generalized 
Time 

<not  applicable  > 

boolean 

BOOLEAN 

<not  applicable  > 

null 

NULL 

<not  applicable  > 

NOTE  -  The  string  length  parameter  specifies  the  actual  number  of  from  the  referenced  character  set.  It  does 
not  include  any  escape  sequences  or  overhead  from  the  encoding. 


12 


part  9  -  FTAM  Phase  2 


September  1991  (Stable) 


jrhe  primitive  data  types  and  minimal  size  ranges  tliat  an  implementation  must  accept  for  storage  are  given 
=  n  table  3. 


Table  3  -  FTAM  primitive  data  types 


■  iiiiiiiiw  woia  1  yuv 

iviinirnuni  nanyo  ^wcxcis^ 

ASN.1  INTEGER 

1  -  2 

ASN.1    BIT  STRING 

0-1 

ASN.1  lASString 

0-  134 

ASN.1  GeneralString 

0-  134 

ASN.1  GraphicString 

0-134 

ASN.1    OCTET  STRING 

0-512 

ASN.1  BOOLEAN 

ASN.1  NULL 

ASN.1  GeneraiizedTlme 

ASN.1  UniversalTime 

NBS-AS1  FloatingPointN  umber 

mantissa  1-23  bits 

exponent  0-8  bits 

NOTES 

1  The  primitive  data  types  and  their  maximum  ranges  for  a  specific  file  as  described  by  the  parameters  above 
are  maintained  in  the  < contents  type>  file  attribute.  The  < contents  type>  file  attribute  value  is  established 
at  the  file's  creation  and  cannot  be  changed  via  FTAM  for  the  life  of  the  file.  This  implies  that  the  data  element 
types  and  ranges  and  data  unit  formats  are  fixed  for  all  accessors  of  that  file  as  long  as  the  file  exists. 

2  The  syntax  for  floating  point  numbers  is  part  of  the  definition  of  NBS  abstract  syntax  ASI  in  annex  C.3.  It 
is  derived  from  existing  standards  lEC  559  and  IEEE  754. 


10.1    Character  set 

implementation  of  a  cliaracter  set  in  FTAM  is  understood  as: 
a  transfer  syntax  is  defined  for  tlie  character  set 

document  types  are  defined  using  the  character  set  in  their  abstract  syntactic  definition 

documents  of  those  types  are  stored  in  the  Virtual  File  Store  as  defined  in  the  character  set 
specification.  They  are  written  into  the  VFS  and  read  from  the  VFS  as  defined  by  the  abstract 
syntax  and  the  transfer  syntax  for  the  document  type.  It  is  not  in  the  scope  of  FTAM  Agreements 
to  specify  the  local  representation  of  those  documents  in  the  Real  Filestore,  nor  to  specify  rendition 
of  graphic  characters  or  control  characters  on  character  imaging  devices.  These  renditions  are 
possible  agreements  between  applications  using  FTAM  for  their  communication. 
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10.1.2      Format  effectors 

When  a  single  format  effector  for  vertical  (or  horizontal)  movement  is  optionally  permitted  to  effect  a 
combined  vertical  and  horizontal  movement,  implementations  shall  not  use  the  single  format  effector  for 
1  effecting  the  combined  vertical  and  horizontal  movement.  It  is  recommended  that  NfST  Implementations 
i  use  <CR><LF>  pairs  as  line  terminators.    Failure  to  follow  this  recommendation  may  result  in  an 
j  Implertientation  which  does  not  interoperate  with  other  implementations  conforming  to  these  agreements; 

NOTES 

1  For  further  information  see  ISO  646:1983,  clauses  4.1.22  and  6.4,  ISO  6429:1988,  clause  E.1.2  and  ISO 
j             4873:1986,  clause  A.3.2. 

2  The  Agreements  require  only  support  of  CO  control  characters  of  ISO  646,  containing  among  others  the 
format  effectors  <CR>  and  <LF>.  It  is  recommended  that  NIST  implementations  use  <CR>  <LF^  pairs  as 
line  terminators. 


10.1.3      8859-1  Character  set 

The  Latin  Alphabet  No.1  (ISO  8859-1)  is  used  to  specify  the  printable  characters  of  GO  and  Gl.  CO  control 
characters  and  their  associated  rules  are  taken  from  the  ISO  646  definition. 


10.2    Document  type  Negotiation  rules 


10.2.1      Connection  establishment 

In  connection  establishment  the  <  contents  type  list>  parameter  is  used  only  to  establish  presentation 
contexts.  Both  the  < document  type  name>  form  and  the  <  abstract  syntax  name>  form  are  supported  for 
Responders;  they  are  optionally  supported  for  Initiators. 
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10.2.2      File  creation 

An  <F-CREATE  request>  FPDU  must  contain  a  <document  type  name>  value  in  its  < initial  attrlbutes> 
parameter. 

If  the  specified  document  type  requires  parameterization,  then  these  parameters  must  be  supplied,  otherwise 
the  <F-CREATE  request>  may  be  rejected. 

NOTES 

1  It  is  understood  that  <  permitted  actions>  sub-field  of  < initial  attributes>  parameter  will  always  be  used  at 
<F-CREATE  request>.  The  value  may  be  changed  by  the  Responder. 

2  If  the  <  document  type  name>  used  requires  DU  syntax  parameters  and  one  of  the  parameters  specifies 
'FIoatingPointNumber'  as  a  primitive  data  type,  the  request  may  be  rejected,  in  case  the  optional  type 
'FioatingPointNumber'  is  not  supported  by  the  Responder. 


10.2.3      File  opening 

The  <  document  type  name>  form  (with  appropriate  parameters  as  specified  in  8871-2,  clause  12.3)  shall 
always  be  used  when  proposing  a  <  contents  type>;  as  an  alternative  the  'ContentsTypeUnknown'  value 
may  be  used  in  the  <F-OPEN  request  >.  An  <F-OPEN  response  >  shall  use  the  <  document  type  name> 
option  (with  appropriate  parameters)  in  the  <  contents  type>  field. 

This  allows  the  receiving  entity  to  use  the  <  document  type  name>  attributed  to  the  file  Instead  of  receiving 
a  <  constraint  set  name>  and  <  abstract  syntax  name>  pair,  which  does  not  reflect  the  file  information 
contained  in  the  FTAM  and  NBS  document  types. 

This  document  type  name  is  either  a  value  from  the  set  of  base  document  type  names  as  negotiated  upon 
connection  establishment  or  a  document  type  name,  for  which  an  appropriate  presentation  context  was 
established. 

NOTES 

1  An  <F-OPEN  response>  without  a  < document  type  name>  (but  carrying  the  <constraint  set  name>  and 
obstract  syntax  name>  form)  may  cause  the  Initiator  to  issue  an  <F-CLOSE  request>. 

2  If  the  <  document  type  name>  used  requires  DU  syntax  parameters  and  one  of  the  parameters  specifies 
'FioatingPointNumber'  as  a  primitive  data  type,  the  request  may  be  rejected,  in  case  the  optional  type 
'FioatingPointNumber'  is  not  supported  by  the  Responder. 


10.3    Reiationship  between  DUs,  DEs  and  document  types 

"Abstract  Syntax"  is  used  to  refer  to  the  syntactic  information  which  is  architecturally  passed  between  the 
Application  and  Presentation  Layers.  The  Abstract  Syntax  defines  Data  Element  (DE)  types  which  are  not 
necessarily  ASN.1  primitive  types.  A  Data  Element  (DE)  is  the  smallest  piece  of  data  whose  identity  is 
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necessarily  preserved  by  the  Presentation  Service.  Data  types  may  be  made  up  of  otiier  data  types.  Data 
Elements  are  not  defined  in  terms  of  other  Data  Elements. 

'  A  Data  Unit  (DU)  is  a  sequence  of  one  or  more  Data  Elements.  Architecturally,  entire,  single  DEs  are  passed 
into  and  out  of  the  application  process.  In  a  real  implementation,  DUs  may  be  passed. 

'I  To  maintain  DU  boundaries  during  transfer,  file  structuring  information  must  be  passed  (IS08571-FADU 
j  definition  in  ISO  8571-2,  clause  7.5).  A  Data  Element  is  referred  to  as  a  File-Contents-  Data-Element  in  the 
j  1808571 -FADU  definition. 

Document  types  refer  to  aspects  of  local  processing  and  storage.  They  describe: 

-  structural  relationship  between  DUs, 

!  -  structure  of  DUs,  called  DU  syntax,  and 

J  -  DE  types  found  in  the  file 

Because  document  types  pertain  to  local  processing  and  storage,  the  DU  syntax  makes  assertions  about 
the  syntax  and  the  size  of  DUs  (records)  in  storage.  Parameters  on  the  document  types  provide  this 
information  about  the  syntax  and  size  of  the  DUs. 


When  an  F-CANCEL  is  sent  or  received,  the  following  occurs: 

-  no  more  data  is  sent, 

-  checkpoint  numbers  are  removed,  and 

-  state  of  the  file  is  implementation  dependent. 

NOTE  -  When  mapping  F-CANCEL  on  P-RESYNCHRONIZE  (abandon)  it  is  required  that  P-SYNC-MINOR  be 


used  after  F-READ/  F-WRITE  (see  ISO  8571-4  clauses  13,  14). 

12  Implementation  information  agreements 

The  < implementation  information >  parameter  of  <F-INITIALIZE>  FPDU  is  not  required  by  these 
Agreements. 

It  may  be  used  to  pass  user  version  information  as  a  series  of  values,  separated  by  ';' 
The  following  will  indicate  conformance  to  the  NIST  Phase  2  Agreements:  NBS-Phase2. 


11    F-CANCEL  action 
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NOTE  -  The  list  of  possible  values  may  be  enlarged  for  future  FTAM  phases  or  FTAM  profiles  of  other  bodies.  ^ 
This  parameter  is  for  information  on!y;  It  Is  not  used  for  negotiation. 

The  establishment  of  an  FTAM  regime  should  not  be  rejected  only  because  of  an  unknown  <  implementation 
information  >  value. 


13  Diagnostic  agreements 

The  <diagnostic>  parameter  is  supported;  a  value  in  the  <response>  PDU  is  needed  when  the  <action 
result >  or  < state  result >  is  not  zero.  (The  nature  of  these  agreements  Is  to  provide  <diagnostic> 
information  when  any  result  parameter  is  not  'success'.) 

General  catch-all  diagnostic  action  is  discouraged. 

The  <further  details>  subfield  is  supported.  It  will  be  encoded  as  GraphlcString,  but  is  restricted  to  ISO  646 
(IRV,  graphic  characters)  and  ISO  8859-1  only. 

Use  of  F-P-ABORT  for  other  than  protocol  errors  and  catastrophic  situations  is  discouraged. 

When  returning  an  error  status  in  a  file  management  related  diagnostic  (i.e.,  <F-READ-ATTRIBUTE 
response>  or  <F-CHANGE-ATTRIBUTE  response>),  Identify  the  erroneous  attribute  by  using  the  first  two 
characters  of  < further  details  >  to  hold  a  2-digit  number  (encoded  as  lASString)  from  the 
<F-READ-ATTRIBUTE  request>  attributes  abstract  syntax  definition  (ISO  8571-4,  clause  20.3). 


00 

Filename 

01 

Permitted  Actions 

02 

Contents  Type 

03 

Storage  Account 

04 

Date  and  Time  of  Creation 

05 

Date  and  Time  of  Last  Modification 

06 

Date  and  Time  of  Last  Read  Access 

07 

Date  and  Time  of  Last  Attribute  Modification 

08 

Identity  of  Creator 

09 

Identity  of  Last  Modifier 

10 

Identity  of  Last  Reader 

11 

Identity  of  Last  Attribute  Modifier 

12 

File  Availability 

13 

File  Size 

14 

Future  Filesize 

15 

Access  Control 

16 

Legal  Qualifications 

17 

Private  Use 

The  set  of  file  management  diagnostics,  found  in  ISO  8571-3  annex  A,  must  be  supported. 


18 


Part  9  -  FT  AM  Phase  2 


December  1990  (Stable) 


In  the  case  where  a  specific  parameter  can  in  no  way  be  acconnmodated  then  the  request  fails  and  a 
<diagnostic>  indicating  one  such  parameter  should  be  returned  by  the  responder.  In  the  case  where  a 
negotiable  parameter  cannot  be  accommodated  with  exactly  the  value  requested  but  is  negotiated  to  a 
different  value  (as  defined  in  the  standard)  then  the  request  formally  succeeds  but  informative  <  diagnostics  > 
indicating  those  parameters  negotiated  should  be  returned. 

In  order  to  provide  for  robust  applications  using  FTAM,  well  defined  and  precise  diagnostics  are  required 
to  be  returned  by  responding  implementations  whenever  an  action  cannot  be  carried  out  precisely  as 
requested  with  respect  to  non-negotiable  parameters.  All  such  applicable  diagnostics  will  be  returned  in 
those  cases.  An  action  is  carried  out  precisely  as  requested  with  respect  to  a  parameter  when  the  value 
of  that  parameter  on  the  <  request  >  FPDU  is  equal  to  the  value  in  effect  during  or  subsequent  to  the  action, 
depending  on  whether  the  action  is  regime  control. 

Diagnostics  exist  to  signal  'parameter  not  supported'  and  Responder  implementations  shall  issue  all 
appropriate  diagnostics.  The  < further  details >  subfield  of  the  <diagnostic>  parameter  shall  specify  the 
parameter  which  is  not  implemented. 


14  Concurrency 

The  <  concurrency  control  >  used  by  default  on  actions  requested  by  an  <F-SELECT  indication  >  or  <F- 
CREATE  indication  >  service  are: 

-  'shared'  for  read  and  read  attribute 

-  'exclusive'  for  all  other  actions 

The  default  for  actions  not  requested  is  specified  as  'not  required'  as  per  ISO  8571-3. 

NOTE  -  A  local  implementation  may  choose  to  be  more  restrictive  in  order  to  assure  file  consistency  for 
concurrent  accessors. 

FADU  locking  is  not  required. 


15  Requested  access 

The  <  requested  access  >  parameter  on  <F-SELECT>  or  <F-CREATE>  is  used  to  specify  the  actions  which 
the  Initiator  may  perform  during  the  file  selection.  The  value  of  the  <  requested  access >  parameter  is 
compared  by  the  Responder  to  the  <  access  control  >  and  <  permitted  actions  >  file  attributes  and 
concurrency  controls  (including  those  requested  by  the  Initiator)  currently  in  place  on  the  file.  If  the  value 
of  the  <  requested  access  >  parameter  is  not  consistent  with  either  <  access  control  >,  <  permitted  actions  >, 
or  concurrency  controls  in  place,  then  the  <F-SELECT>  or  <F-CREATE>  must  be  rejected. 

<requested  access>  is  consistent  with  <access  control >  if,  for  each  action  requested,  that  action  either 
requires  no  password,  or  the  required  password  has  been  specified  on  the  <F-SELECT  request>  or  <F- 
CREATE  request  >. 
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< requested  access>  is  consistent  with  < permitted  actions>  if,  for  each  action  requested,  that  action  is 
allowed  by  the  <  permitted  actions  >  file  attribute. 

<  requested  access  >  is  consistent  with  <  concurrency  control  >  requested  on  the  <F-SELECT>  or  <F- 
CREATE>  if,  for  each  action  requested,  that  action  has  not  been  specified  as  'not  required'  or  'no  access' 
in  the  <  concurrency  control  >  parameter. 

<  requested  access  >  is  consistent  with  concurrency  controls  in  place  on  the  file  if  for  each  action  requested 
no  other  accessor  of  the  file  has  set  the  concurrency  control  for  that  action  to  either  'exclusive'  or  'no 
access'. 


16  Security 


16.1     Initiator  identity  and  filestore  password 

The  < initiator  identity >  and  <filestore  password >  parameters  for  an  implementation  acting  as  an  Initiator 
are  supported.  These  parameters  are  optional  for  an  implementation  acting  as  a  Responder. 

The  syntax  of  <  initiator  identity >  and  <filestore  password  >  is  system-dependent.  < initiator  identity >  and 
<filestore  password  >  will  represent  account  information  on  the  local  system,  which  may  be  different  from 
the  <  account  >  parameter. 


16.2    Access  passwords 

The  < access  passwords >  and  <  create  password  >  parameters  for  an  implementation  acting  as  an  Initiator 
are  supported  if  the  Security  Group  of  attributes  is  supported.  These  parameters  for  an  implementation 
acting  as  a  Responder  are  optionally  supported  if  the  Security  Group  is  supported. 


16.3    Implementation  responsibilities 

It  is  the  responsibility  of  each  local  system  to  provide  security  for  its  own  real  filestore.  Encryption  of 
passwords  will  not  be  done  by  FTAM. 

A  user  of  the  file  service  must  be  known  by  the  Responder.  "Known"  is  defined  by  the  local  Filestore,  and 
is  dependent  on  the  level  of  security  provided  by  the  local  Filestore. 


17   Requirement  for  conformant  implementations 

This  clause  gives  the  criteria  to  be  satisfied  by  every  implementation  of  FTAM  that  conforms  to  these 
Agreements. 
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Conformance  to  these  Agreements  is  stated  in  terms  of  tlie  different  roles  occupied  by  FTAM 
Implementations.  The  interoperability  of  certain  configurations  of  these  roles  motivates  this  approach. 
Interoperable  configurations  of  these  roles  are  given  in  17.1. 

The  only  function  provided  by  every  conformant  implementation  is  the  transfer  of  unstructured  binary  files 
j  in  their  entirety.  It  must  be  recognized  that  such  simple  transfer,  while  commonly  understood  and  generally 
I  important,  will  not  support  all  applications  of  FTAM.  Clause  18  defines  Implementation  Profiles  of  FTAM 
I  services  and  protocol  that  can  provide  other  specific  functions.  Those  other  functions  exploit  the  access 
j  and  management  capabilities  of  FTAM.  The  unconstrained  service  class  (with  appropriately  chosen  functional 
!  units)  can  be  used  to  provide  the  functions  of  any  of  the  Implementation  Profiles.  Users  of  FTAM  must 

consider  carefully  what  functions  they  require.  They  must  examine  all  the  Implementation  Profiles  and  select 

according  to  their  needs. 

Implementation  conforming  to  these  Agreements  require  adherence  to  the  General  Agreements  in  clauses 
5  through  16  of  these  Agreements. 

l^mp^enientations  conforming  to  these  agreemems  shall  im|:Memenf  the  defect  report  solutions  contained  mi 


tSO  8571 
t$08571 

-1/Cor<t:1990 
-2/CQf.tt1990 

ISO  B67t 

»a/Cor>1:1990 

ISO  857f-4/Cor.t:1990 

! 


tSO  8571 -3/CQr.2t1 990 
fSO  8$7t-4/Cor.a:1990 

Editor's  l4ote  -  The  corrigmda  ISO  857i'3/Cof.2  ancJ  ISO  ^7l-4/Cof.2  to  be  published,  until  it  j$ 
ItvaJlahl^,  the  $oluftor»&  csn  be  found  In  the  documents  t$0/l£C  .ITCl/$C2 1  N  5234  and  ISO/IEG  JTC1  /$C2$ 


17.1     Interoperable  configurations 

Any  implementation  conforming  to  this  specification  must  be  able  to  act  in  at  least  one  of  the  following  role 
Ij  combinations: 

1 .  initiator  and  receiver, 

2.  Initiator  and  sender, 

3.  responder  and  sender, 

I  4.        responder  and  receiver. 

Minimal  Implementations  of  combination  1  will  interoperate  with  minimal  implementations  of  combination  3. 
Minimal  implementations  of  combination  2  will  interoperate  with  minimal  implementations  of  combination  4. 
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Any  implementations  of  roles  1  and  3  will  be  able  to  interoperate  at  the  intersection  of  their  capabilities 
(which  will  be  at  least  the  minimal  capabilities  described  in  17.3  to  17.8).  Any  implementations  of  roles  2 
and  4  will  be  able  to  interoperate  at  the  intersection  of  their  capabilities  (which  will  be  at  least  the  minimal 
capabilities  described  in  17.3  to  17.8). 

These  role  combinations  and  this  interoperability  are  shown  in  table  5  below. 


Table  5  -  Interoperable  configurations. 


InHlator 

Responder 

sender 

receiver 

sender 

receiver 

initiator 

sender 

X 

receiver 

X 

Responder 

sender 

X 

receiver 

X 

17.2    Relationship  to  ISO  8571 -The  FTAM  Standard 

Any  implementation  in  conformance  to  ISO  8571  (as  defined  in  ISO  8571-4,  clause  22  (Conformance)),  in 
addition  to  the  implementation  of  the  minimal  protocols  and  roles  enumerated  in  subclauses  17.3  to  17.8, 
is  considered  to  be  in  conformance  with  these  Agreements.  Any  implementation  violating  any  of  the 
conformance  statements  in  ISO  8571-4  is  considered  to  be  in  violation  of  these  Agreements. 


17.3    Requirements  for  document  type  support 

The  document  type  FTAM-3  shall  be  supported  for  purposes  of  transfer  and  storage.  The  details  regarding 
support  for  FTAM-3  in  the  FTAM  dialogue  are  given  in  clause  10. 

Support  of  document  types  other  than  FTAM-3  is  not  required  for  conformant  implementations.  Support 
for  document  types  described  in  these  Agreements  also  entails  support  for: 

the  semantics  given  in  their  description  and  further  qualified  in  clause  10 

the  preferred  transfer  syntax  "Basic  Encoding  of  a  single  ASN.1  type" 
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9  17.4  Initiators 

'  Every  implementation  of  an  FTAM  Initiator  shall  support: 

'  the  kernel  protocol  and  its  nnandatory  parameters  with  minimum  ranges  [Minimum  required  ranges 

are  specified  in  17.8.], 

j  the  grouping  protocol  and  the  <threshold>  parameter  with  a  value  of  at  least  2  for  use  in  the  file 

I  transfer  class, 


22-1 


I 

i 

\ 

i 


Part  9  -  FTAM  Phase  2 


December  1990  (Stable) 


Should  the  supporting  services  break  down,  such  that  FTAM  communication  is  impossible,  the  FTAM 
protocol  machine  shall  notify  the  user  with  an  <F-P-ABORT  indication>  and  <diagnostic>  with  identifier 
1011,  as  well  as  inform  the  user  of  any  known  <further  details>. 

17.6  Senders 

Every  implementation  of  an  FTAM  sender  shall  support  the  read  functional  unit  as  Responder  or  the  write 
functional  unit  as  Initiator,  and  support  the  applicable  procedures  defined  in  ISO  8571-4  clauses  11  (State 
of  the  bulk  data  transfer  activity),  12  (Bulk  data  transfer  protocol  data  units),  15  (Bulk  data  transfer  sending 
entity  actions),  17.1  (Discarding),  and  17.2  (Cancel). 

To  support  those  procedures  the  Implementation  shall  be  able  to  send  files  of  the  document  type  FTAM-3 
and  shall  be  able  to  send  them  as  user  data  in  PPDUs  In  blocks  of  up  to  7168  octets. 

17.6.1  Initiator  Senders 

Every  implementation  of  an  FTAM  sender  which  is  also  an  FTAM  Initiator  shall  support: 

-  the  write  functional  unit  and  protocol,  and 

-  for  the  document  type  FTAM-3  the  following  bulk  data  transfer  specification  parameters: 

-  FADU  operation  replace 

-  FADU  identity  first 

and  support  the  applicable  procedures,  defined  in  ISO  8571-4  clause  13  (Bulk  data  transfer 
initiating  entity  actions). 

17.6.2  Responder  Senders 

Every  implementation  of  an  FTAM  sender  which  is  also  an  FTAM  Responder  shall  support: 

-  the  read  functional  unit  and  protocol,  and 

-  for  the  document  type  FTAM-3  the  following  bulk  data  transfer  specification  parameters: 

1)  FADU  identity  first 

2)  Access  context  UA 

and  support  the  applicable  procedures,  defined  in  ISO  8571  -4  clause  1 4  (Bulk  data  transfer  responding  entity 
actions). 
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Every  implementation  of  an  FTAM  receiver  shall  support  the  read  functional  unit  as  Initiator  or  the  write 
functional  unit  as  Responder,  and  support  the  applicable  procedures,  defined  in  ISO  8571-4  clauses  11 
(State  of  the  bulk  data  transfer  activity),  12  (Bulk  data  transfer  protocol  data  units),  16  (Bulk  data  transfer 
receiving  entity  actions),  17.1  (Discarding),  and  17.2  (Cancel). 

To  support  those  procedures  the  implementation  shall  be  able  to  receive  files  of  the  document  type  FTAM-3 
and  shall  be  able  to  receive  them  as  user  data  in  PPDUs  in  blocks  of  at  least  7168  octets. 

17.7.1  Initiator  Receivers 

Every  implementation  of  an  FTAM  receiver  which  is  also  an  FTAM  Initiator  shall  support: 

-  the  read  functional  unit  and  protocol,  and 

-  for  the  document  type  FTAM-3  the  following  bulk  data  transfer  specification  parameters: 

1)  FADU  identity  first 

2)  Access  context  UA 

and  support  the  applicable  procedures,  defined  in  ISO  8571-4  clause  13  (Bulk  data  transfer  initiating  entity 
actions). 

17.7.2  Responder  Receivers 

Every  implementation  of  an  FTAM  receiver  which  is  also  an  FTAM  Responder  shall  support: 

-  the  write  functional  unit  and  protocol,  and 

-  for  the  document  type  FTAM-3  the  following  bulk  data  transfer  specification  parameters; 

1)  FADU  operation  replace 

2)  FADU  identity  first 

and  support  the  applicable  procedures,  defined  in  ISO  8571  -4  clause  1 4  (Bulk  data  transfer  responding  entity 
actions). 
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17.8    Minimum  ranges 

Any  implementation  of  any  conformant  FTAM  configuration  sfiall  be  able  to  receive  and  meaningfully  process 
all  mandatory  parameters  for  all  functional  units  supported  as  well  as  the  <diagnostic>  parameter  within 
at  least  the  minimum  ranges  of  values  given  in  table  6.  A  conforming  implementation  may  support  a  wider 
range  of  values  for  any  parameter. 
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Parameter 

Minimum  Range 

general 

diagnostic 

Values  as  specified  in  ISO  8571-3  annex  A 
(Diagnostic  parameter  values)  tables  44,  45 
and  46  which  correspond  directly  to 
mandatory  parameters. 

action  result 

Mil  values 

state  result 

All  values 

Tunciionai  uniis 

'read'  (for  initiator/receivers  and 
responder/senders)  and  'grouping' 
or 

'write'  (for  initiator/senders  and 
responder/receivers)  and  'grouping' 

presentation  context 

1 1  lai  laycll  ici  U 

'False' 

all  Others 

As  specified  in  17.4  and  17.5  above 

F-SELECT 

attributes 

Only  <fi!ename>  is  used  with  a  minimum 
supportable  length  of  8  characters.  Any 
other  attribute  supported  for  other  services 
must  have  minimum  supported  lengths  as 
in  ISO  8571-2  clause  15  (Minimum  attribute 
ranges),  table  2. 

requested  access 

'read'  for  initiator/receivers 
'read'  for  responder/senders 
'replace'  for  initiator/senders 
'replace'  for  responder/receivers 

F-CREATE 

override 

For  Responders,  the  values  'create-failure', 
'select-old-file'  and  'delete-and-create-with- 
new-attributes'  are  supported.  The  value 
'delete-and-create-with-old-attributes'  is 
optionally  supported.  All  values  are  optional 
for  Initiators. 
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Table  6  -  Required  minimal  parameter  support,  (concluded) 


Parameter 

Minimum  Range 

F-OPEN 

processing  mode 

'read'  for  initiator/receivers 
'read'  for  responder/senders 
'replace'  for  initiator/senders 
'replace'  for  responder/receivers 

contents  type 

'FTAM-3' 

F-READ 

FADU  identity 

'first' 

access  context 

'UA' 

F-WRITE 

FADU  operation 

'read'  for  initiator/receivers 
'read'  for  responder/senders 
'replace'  for  initiator/senders 
'replace'  for  responder/receivers 

FADU  identity 

'first' 

F-BEGIN- 
GROUP 

threslnold^ 

For  file  transfer  (a  minimal  required 
function)  2 

For  any  other  supported  parameters,  minimum  ranges  are  taken  from  the  minimum  ranges  for  the  attribute 
corresponding  to  each  as  in  ISO  8571-2  table  4. 

NOTES 

1  The  parameters,  functional  units,  and  presentation  context  management  are  not  ordered,  so  "minimum 
value"  cannot  be  formally  defined.  The  above  values  are  those  required  for  conformance  to  these  Agreements 
but  no  value  conformant  to  ISO  8571  for  use  in  other  applications  is  regarded  to  be  in  violation  of  these 
Agreements. 

2  Other  functional  units  (and  service  classes)  for  defined  implementations  may  also  be  valid  provided  that  they 
are  implemented  in  accordance  with  these  Agreements,  specifically  subclause  1 7.8. 

3  Every  implementation  must  support  the  <  threshold  >  value  2  to  provide  the  basic  required  function  of  file 
transfer;  any  other  value  in  other  applications  is  acceptable. 
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17.9  Range  of  values  for  INTEGER  type  parameters 

The  general  range  for  parameters  of  type  INTEGER  to  the  FTAM  PCI  is  as  specified  in  the  UNIVERSAL 
ASN.1  ENCODING  RULES  clause  of  the  Upper  Layers  part.  , 

The  parameters  ^ 

-  FTAM  Attributes  | 

X 

-  filesize  ^ 

-  future-filesize  I 

-  FADU-ldentity  I 

-  fadu-number  1 
may  be  encoded  so  that  the  length  of  its  contents  octets  is  no  more  than  eight  octets. 

In  the  case  of  receiving  more  than  4  contents  octets,  the  receiver  may  reject  the  corresponding  FTAM  PDU. 

NOTE  -  To  guarantee  interworking,  encoding  should  be  restricted  to  the  range  -2^^  to  2^^-1.  j  | 

\ 

17.10  Use  of  lower  layer  services 

Support  for  the  Presentation  Context  Management  functional  unit  is  not  required. 

implementations  will  support  the  Session,  Presentation,  and  ACSE  requirements  as  stated  in  part  5  of  this 
document.  i 

NOTE  -  Implementation  of  the  Session  Resychronize  and  the  Minor  Synchronize  functional  units  is  highly  ' 
recommended,  since  the  F-CANCEL  service  may  be  less  effective  v\/hen  mapped  to  S-DATA. 

18   Implementation  Profiles 

This  clause  defines  Implementation  Profiles  for  the  specific  functions  of: 

-  File  Transfer 

-  File  Access 

-  File  Management 

30 


m 


Part  9  -  FTAM  Phase  2  December  1990  (Stable) 

Those  definitions  are  expressed  in  terms  of: 

-  Document  Types 

-  Attributes 

-  Service  Classes  (both  service  elements  and  their  parameters). 

This  by  no  means  defines  all  possible  Implementation  Profiles.  The  following  Implementation  Profiles  are 
defined: 

-  T1  :  Simple  File  Transfer 

-  T2  :  Positional  File  Transfer 

-  T3  :  Full  File  Transfer 

-  A1  :  Simple  File  Access 

-  A2  :  Full  File  Access 

-  M1  :  Management. 

Implementation  Agreements  have  been  reached  for  the  following  service  classes. 

-  File  Transfer 

-  File  Access 

-  File  Management 

-  Unconstrained 

-  File  Transfer  and  Management 

NOTE  -  Any  given  implementation  may  support  more  than  one  service  class. 
Support  of  an  Implementation  Profile  requires  adherence  to: 

-  corresponding  definition  in  8571-3  clause  8  and  any  related  procedures  in  8571-4 
clause  8-17, 

-  requirements  given  in  clauses  5-18  of  these  Agreements,  and 

-  requirements  for  parameter  and  attribute  support  as  defined  in  17.8. 
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18.1  General  requirements  for  the  defined  Implementation  Profiles 

Implementations  will  be  able  to  act  either  as  Initiator  or  Responder  or  both. 

Implementations  must  support  diagnostics  as  described  in  clause  13  of  these  Agreements. 

Implementations  that  support  the  file  access  service  class  will  support  access  to  sequential  files.  Support 
of  sequential  files  entails  hierarchy  of  depth  and  arc  length  equal  to  1 .  Other  hierarchy  depth  and  arc 
lengths  are  not  precluded  by  these  agreements. 

18.2  (deleted) 

18.3  Document  type  requirements  for  the  defined  Implementation 
Profiles 

Implementations  conformant  to  Implementation  Profiles  defined  in  table  7  will  support  the  following 
document  types  with  the  caveats  and  procedures  given. 

-  FTAM-1 

-  FTAM-2 

-  FTAM-3 

-  NBS-6 

-  NBS-7 

-  NBS-8 

-  NBS-9 
NOTES 

1  Support  of  this  document  type  entails  the  naming  of  FADUs  by  their  position  in  preorder  traversal. 

2  Caveat:  Other  methods  of  naming  FADUs  depend  on  the  system,  application,  and  specific  file,  and  as  such 
are  not  described  here. 

3  Those  document  types  are  defined  in  annex  A  and  clause  10  of  these  Agreements,  and  in  ISO  8571-2. 

Support  for  any  document  type  requires  the  ability  to  transfer  and  store  the  abstract  syntax  given  in  its 
definition.  These  Agreements  do  not  specify  techniques  or  formats  for  storage. 
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NOTE  -  Specific  abstract  syntaxes  for  the  parameterized  document  types  NBS-6,7,8  are  not  specified  in  these 
Agreements. 

Any  document  type  supported  must  be  identifiable  by  its  document  type  name  as  given  in  ISO  8571-2  and 
in  annex  A  of  these  Agreements  and,  where  defined,  the  parameterization  scheme  given  in  clause  10  of 
these  Agreements. 

For  conformance  to  NBS-9  a  Responder  is  only  required  to  return  the  <filename>  attribute,  subject  to  local 
security  and  access  control.  All  other  requested  attributes  need  not  be  returned. 

Systems  supporting  the  NBS-9  document  type  shall  make  available  an  NBS-9  document  called  'DIRLIS'. 
This  document  can  be  used  to  obtain  a  listing  of  files  and  their  associated  attributes  from  a  remote  Filestore. 

Creation  and  deletion  of  NBS-9  files  are  outside  the  scope  of  these  Agreements. 

File  security  issues  related  to  NBS-9  are  subject  to  the  security  agreements  outlined  in  clause  16. 


18.4    Parameters  for  the  defined  Implementation  Profiles 

1   Implementations  will  support  the  <contents  type  list>  parameter  on  the  <F-INITIALIZE>  service  element. 
The  initiating  service  must  supply  a  value  for  this  fDarameter. 

Implementations  will  support  the  <diagnostic>  parameter  as  stated  in  clause  13  of  these  Agreements. 

j  The  <  initiator  identity >  parameter  is  supported.  Use  must  be  consistent  with  clause  16  of  these 
'  Agreements. 

I   Implementations  are  not  precluded  from  using  other  parameters  for  security  and /or  accounting.  Responders 
!   must  state  the  syntax  and  the  semantics  applying  to  <  account  >  and  <  charging  >  parameters.  The 
Responder's  minimum  implementation  is  to  accept  but  ignore  the  <  account  >. 


18.5    Parameter  ranges  for  the  defined  Implementation  Profiles 

Parameter  ranges  for  Implementations  Profiles  are  as  stated  for  primitive  data  types  in  clause  10  of  these 
Agreements. 


18.6    File  attribute  support  for  Implementations 

Implementations  of  the  Implementation  Profiles  will  support  file  attributes  or  attribute  groups  in  the  following 
ways: 

a)  mandatory  -  This  feature  is  mandatory  in  the  ISO  8571-2  standard  and  shall  therefore 
be  implemented  by  all  implementations  claiming  conformance  to  these  Agreements; 
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b)  supported  -  This  feature  shall  be  implemented  by  all  implementations  claiming 
conformance  to  these  Agreements  (for  attributes,  this  implies  that  at  least  the  minimum 
range  of  attribute  values,  as  defined  in  ISO  8571-2  clause  15,  shall  be  supported). 
Conformant  implementations  shall  also  be  able  to  interwork  with  other  implementations 
that  do  not  support  this  feature  by  negotiating  out  the  corresponding  features; 

c)  optionally  supported  -  Implementations  claiming  conformance  to  these  Agreements 
may  or  may  not  implement  this  feature  (for  attributes,  this  implies  that  at  least  either  the 
minimum  range  of  attribute  values,  as  defined  in  ISO  8571-2  clause  15,  shall  be 
supported  or  that  the  'no  value  available'  result  shall  be  supplied).  If  an  attribute  group 
with  a  support  level  of  'optionally  supported'  is  chosen  to  be  supported,  then  all  the 
attributes  of  this  group  that  are  classified  as  'mandatory'  or  'supported'  shall  be 
supported; 

d)  not  supported  -  This  feature  is  outside  the  scope  of  these  Agreements. 
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Kernel  Group 

Filename 
Permitted  Actions 
Contents  Type 


mandatory 
mandatory 
mandatory 
mandatory 


Storage  Group 

Storage  Account 

Date  and  Time  of  Creation 

Date  and  Time  of  Last  IVIodification 

Date  and  Time  of  Last  Read  Access 

Date  and  Time  of  Last  Attribute  Modification 

Identity  of  Creator 

Identity  of  Last  Modifier 

Identity  of  Last  Reader 

Identity  of  Last  Attribute  Modifier 

File  Availability 

Filesize 

Future  Filesize 


optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
supported 
supported 

optionally  supported 


Security  Group 
Access  Control 
Legal  Qualifications 


optionally  supported 
supported 

optionally  supported 


Private  Group 


not  supported 
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Table  7  -  Implementation  profile  support  requirements 


Functional  Units 

Service  Classes  (see  note  8) 

T 

M 

A 

TM 

Uncon- 
strained 

Kernel 

T1 , 12,  13 

Ml 

A1,  A2 

see 

note  4 

see 
note  5 

Read   (see  note  3) 

T1 ,  T2,  T3 

A1,  A2 

Write   (see  note  3) 

11 ,  12,  T3 

A1,  A2 

Limited  File 
Management 

see  note  6 

Ml 

see  note  6 

Enhanced  File 
Management 

Ml 

Grouping 

T1 ,  T2, 13 

Ml 

File  Access 

A1,  A2 

Document  Types 

FTAM-1 

11 ,  T2,  T3 

[Ml] 

A1,  A2 

FTAM-2 

12, 13 

[Ml] 

A1,  A2 

FTAM-3 

71 ,  12,  T3 

[Ml] 

A1,  A2 

NBS-6 

[T2],  73 

[Ml] 

[A1],  A2 

NBS-7 

[72],  73 

[Ml] 

[A1],  A2 

NBS-8 

73 

[Ml] 

A2 

NBS-9 

[T1],  [72], 
[73] 

[Ml] 

NOTES 

to  18.3  and  table  7 

1  The  Management  Implementation  Profile  is  only  to  be  implemented  in  conjunction  with  one  of  the  Transfer 
or  Access  Profiles. 

2  Profile  T2  is  subset  of  T3.  A1  and  T1  are  subsets  of  A2  and  T2,  respectively. 

3  Profiles  T1, 12,  and  T3  require  the  support  of  read  and/or  write  functional  units. 
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4  Support  of  the  <File  Transfer  and  Management>  service  class  is  optional.  The  rules  for  including  it  in  a 
request  and  for  the  response  to  it  are  as  given  in  ISO  8571-3,  clause  10.1.  Any  implementation  including  TM 
in  the  request  must  be  prepared  for  the  possibility  that  it  might  be  removed  from  the  response. 

5  The  support  of  the  <  Unconstrained >  service  class  is  outside  the  scope  of  these  Implementation  Profiles. 

6  Limited  File  Management  is  not  required  for  the  T-  and  A-  Implementation  Profiles,  but  very  often  it  be 
a  user  request  to  have  limited  file  management  functionality  available  together  with  file  transfer  and  file  access 
functions.  So  Limited  File  Management  may  be  added  as  an  option  to  the  T-  and  A-  Implementation  Profiles. 

7  [  ]  in  table  7  specifies  that  the  document  type  is  optional  for  the  respective  Implementation  Profile.  For  M1 
the  support  level  depends  on  the  T-  or  A-  Implementation  Profile,  in  conjunction  with  which  Ml  is  implemented. 

8  The  Implementation  Profiles  specify  functionality  which  includes  the  requirements  for  conformant 
implementations  as  specified  in  clause  1 7.  This  is  a  general  basic  requirement  and  is  not  also  reflected  in  table 
7. 

19   PROVISION  OF  SPECIFIC  FUNCTION 

19.1  Implementation  Profile  T1 :  Simple  File  Transfer 

Implementation  Profile  T1  provides  the  function  of  transferring  entire  files  at  the  external  file  service  level  for 
files  with  an  unstructured  constraint  set.  This  includes  support  of  the  document  types: 

-  FTAM-1       "ISO  FTAM  unstructured  text" 

-  FTAM-3      "ISO  FTAM  unstructured  binary" 

-  NBS-9        "NBS-9  file  directory  file"  (optional) 

This  Implementation  Profile  supports  file  transfer  and  not  file  access,  that  is,  the  ability  to 

-  read  a  complete  file,  and/or 

-  write  (replace,  extend)  to  a  file. 

19.2  Implementation  Profile  T2:  Positional  File  Transfer 

Implementation  Profile  T2  provides  the  function  of  transferring  files  at  the  external  file  service  level  for  files 
with  an  unstructured  or  flat  constraint  set.  This  includes  support  of  the  document  types: 

-  FTAM-1      "ISO  FTAM  unstructured  text" 

-  FTAM-2      "ISO  FTAM  sequential  text" 
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-  FTAM-3 


ISO  FTAM  unstructured  binary' 


-  NBS-6 


NBS-6  FTAM  sequential  file" 


(optional) 


-  NBS-7 


NBS-7  FTAM  random  access  file' 


(optional) 


-  NBS-9 


NBS-9  file  directory  file" 


(optional) 


This  Implementation  Profile  supports  file  transfer  and  not  file  access,  that  is,  the  ability  to 

-  read  a  complete  file  or  a  single  FADU  which  is  identified  by  position,  and/or 

-  write  (replace,  extend,  insert  depending  on  constraint  set  and  document  type)  to  a  file 
or  an  FADU. 

This  Implementation  Profile  is  upwardly  compatible  to  T1  for  the  transfer  of  unstructured  files. 

19.3    Implementation  Profile  T3:  Full  File  Transfer 

Implementation  Profile  T3  provides  the  function  of  transferring  files  at  the  external  file  service  level  for  files 
with  an  unstructured,  flat  or  general  hierarchical  constraint  set.  This  includes  support  of  the  document 
types: 

-  FTAM-1       "ISO  FTAM  unstructured  text" 

-  FTAM-2      "ISO  FTAM  sequential  text" 

-  FTAM-3      "ISO  FTAM  unstructured  binary" 

-  NBS-6        "NBS-6  FTAM  sequential  file" 

-  NBS-7       "NBS-7  FTAM  random  access  file" 

-  NBS-8        "NBS-8  FTAM  indexed  file" 

-  NBS-9        "NBS-9  file  directory  file"  (optional) 

This  Implementation  Profile  supports  file  transfer  and  not  file  access,  that  is,  the  ability  to 

-  read  a  complete  file  or  a  single  FADU  which  is  identified  by  key  or  by  position,  and/or 

-  write  (replace,  extend,  insert  depending  on  constraint  set  and  document  type)  to  a  file 
or  an  FADU. 

This  Implementation  Profile  is  upwardly  compatible  to  T1  for  the  transfer  of  unstructured  files. 
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19.4  Implementation  Profile  A1:  Simple  File  Access 

Implementation  Profile  A1  provides  the  function  of  transfer  of  and  access  to  files  witfi  unstructured  or  flat 
constraint  sets  at  the  external  file  service  level.  This  includes  support  of  the  document  types: 

-  FTAM-1  "ISO  FTAM  unstructured  text" 

-  FTAM-2  "ISO  FTAM  sequential  text" 

-  FTAM-3  "ISO  FTAM  unstructured  binary" 

-  NBS-6  "NBS-6  FTAM  sequential  file"  (optional) 

-  NBS-7  "NBS-7  FTAM  random  access  file"  (optional) 

This  Implementation  Profile  supports  file  transfer  and  file  access,  that  is  the  ability  to 

-  read  a  connplete  file  or  FADUs  which  are  identified  by  position, 

-  write  (replace,  extend,  insert  depending  on  constraint  set  and  document  type)  to  a  file 
or  an  FADU, 

-  locate  and  erase  within  files. 

19.5  Implementation  Profile  A2:  Full  File  Access 

Implementation  Profile  A2  provides  the  function  of  transfer  of  and  access  to  files  with  unstructured  or  flat 
constraint  sets  at  the  external  file  service  level.  This  includes  support  of  the  document  types: 

-  FTAM-1  "ISO  FTAM  unstructured  text" 

-  FTAM-2  "ISO  FTAM  sequential  text" 

-  FTAM-3  "ISO  FTAM  unstructured  binary" 

-  NBS-6  "NBS-6  FTAM  sequential  file" 

-  NBS-7  "NBS-7  FTAM  random  access  file" 

-  NBS-8  "NBS-8  FTAM  indexed  file" 

This  Implementation  Profile  supports  file  transfer  and  file  access,  that  is,  the  ability  to 
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-  read  from  a  complete  file,  or  from  a  series  of  FADUs  which  are  identified  by  key  or  by 
position, 

-  write  (replace,  extend,  insert  depending  on  constraint  set  and  document  type)  to  a  file 
or  an  FADU, 

-  locate  and  erase  within  files. 

19.6    Implementation  Profile  M1 :  Management 

Implementation  Profile  M1  provides  the  function  for  an  Initiator  to  manage  the  files  within  the  Virtual  Filestore, 
to  which  access  is  provided  by  the  Responder.  Management  includes  the  services  of: 

-  creating  a  file 

-  deleting  a  file 

-  reading  attributes  of  a  file 

-  changing  attributes  of  a  file. 

20  Harmonization 

The  Implementation  Protiles  for  File  Transfer,  File  Access  and  Management  correspond  to  the  Profiles  of 
SPAG  (Standards  Promotion  and  Application  Group)  in  Europe,  so  that  interworking  will  be  possible.  Those 
Profiles  are  described  in  the  'Guide  to  the  Use  of  Standards'  (GUS);  they  are  the  basis  for  the  Functional 
Standards  as  defined  by  CEN/CENELEC  (Comite  Europeenne  de  Normalization). 

Table  8  -  Implementation  Profiles  (NIST)  and  Profiles  (SPAG/CEN-CLC)  


Implementation  Profile 

SPAG  /  CEN-CENELEC 

T1 

A/111 

T2 

A/112 

T3 

A/113 

A1 

A/ 122 

A2 

A/ 123 

M1 

A/13 
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Annex  A  (normative) 
FTAM  Document  Types 


thd  obiecte  defi 

nad  i»  A^Hirough  AA^  9^^,  <X3  and  0.4     be  removed  from  this  document 

after  ISO/lEC  ISP 

10607*2  end  tSO/$eC  1^  %Q&Sr-2/AmtiA  «Pe  puWj$h«d<  Dt^Jng  the  pertod  between 

publishing  ihe  i$P 

aitd  renfio«Ed 

of  the 

di^nitions  kom  this  4[locument,  the  defini^ons  in  the  ISP  will  take 

precedencsa 
and  C.2  vm9 

changed  to  point 

When 
tolhd 

me  ob|ect  <;jeiitni^n&  are  removed,  claoeee  At  through  ^i^j^Af^C^^ 
mm 

The  objects  defined  in  A.5  through  A.8,  B.2,  C.3  and  C.4  will  be  removed  from  this  document  after  ISO/lEC 
j  ISP  10607-2  and  ISO/lEC  ISP  10607-2/Amd.1  are  published.  During  the  period  betweem  publishing  the  ISP 

and  removal  of  the  definitions  from  this  document,  the  definitions  in  the  ISP  will  take  preceedence  over  this 
j  document.  When  the  object  definitions  are  removed,  clauses  A.1  through  A.4,  B.1,  C.I  and  C.2  will  be 
'  changed  to  point  to  the  ISP. 

;  A.1      NBS-6  Sequential  file  document  type 


This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(1 )  document-type(5)  sequential (6)} 

was  withdrawn  on  March  16,  1990.  It  was  replaced  with  the  object  NBS-6  Sequential  file  document  type 
with  the  Object  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5)  sequential (6)} 
defined  in  part  9,  A.5. 


i  A.2      NBS-7  Random  access  file 

1  This  object  with  Object  Identifier 

I  {iso  identified-organization  icd(9999)  organization-code(1 )  document-type(5)  random-file(7)} 

was  withdrawn  on  March  16,  1990.  It  was  replaced  with  the  object  NBS-7  Random  access  file  document 
type  with  the  Object  Identifier 

j  {iso  identified-organization  oiw(14)  ftamsig{5)  document-type(5)  random-access(7)} 

defined  in  part  9,  A.6. 
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A.3      NBS-8  Indexed  sequential  file 

This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(1 )  document-type(5)  indexed-file(8)} 

was  withdrawn  on  March  16, 1990.  It  was  replaced  with  the  object  NBS-8  Indexed  sequential  file  document 
type  with  the  Object  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5)  indexed-file(8)} 
defined  in  part  9,  A.7. 


This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(1 )  document-type(5)  file  directory(9)} 

was  withdrawn  on  March  16, 1990.  It  was  replaced  with  the  object  NBS-9  File  directory  file  document  type 
with  the  Object  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5)  file-directory (9)} 
defined  in  part  9,  A.8. 


A.4      NBS-9  File  directory  file 


A.5 


NBS-6  Sequential  file  document  type 


A.5.1 


Entry  Number:  NBS-6 


A.5.2 


Information  objects 
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Table  9  -  Information  objects  in  NBS-6 


document  type  name 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 
sequential(6)} 

■NBS-6  FTAM  sequential  file" 

abstract  syntax  names: 

a)  name  for  asnamel 

{iso  identified-organization  oiw(14) 
ftamsig(5)  abstract-syntax(2)  nbs-as1(1)} 
"NBS  abstract  syntax  ASr 

b)  name  for  asname2 

{iso  standard  8571  abstract-syntax(2)  ftam-fadu(2)} 
■FTAM  FADU" 

transfer  syntax  names: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  Encoding  of  a  single  ASN.1  type" 

parameter  syntax: 

PARAMETERS  ::=  SEQUENCE  OF  CHOICE  {ParameterO,  Parameterl,  Parameter2} 
ParameterO  ::=  [0]  INTEGER  {univer-time  (23), 

gen-time  (24), 

boolean  (1), 

null  (5)  } 

Parameterl  ::=  [1]  SEQUENCE  { 

universal-class-number-1  INTEGER  {  int  (2), 

bit  (3), 
ia5  (22), 
graphic  (25), 
general  (27), 
octet  (4)}, 

string-length  INTEGER  } 
Parameter2  ::=  [2]  SEQUENCE  { 

private-class-number  INTEGER  {float  (0)}, 
length-1  INTEGER, 
length-2     INTEGER  } 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set(4)  sequential-ftat(2)} 
"FTAM  sequential  flat  constraint  set" 

file  contents: 

Datatypel  ::=  PrimType  -  as  defined  in  annex  C.3  NBS-AS1 

Datatype2  ::=  Node-Descriptor-Data-Element 
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A.5.3       Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  by  FTAM. 
NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 


A.5.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer,  Access  and 
Management 


A.5.5  Definitions 

This  definition  mal<es  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 


A.5.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 


A.5.7       Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units.  Each  FADU  contains  precisely  zero  or 
one  data  unit  which  consists  of  zero,  one  or  more  data  elements.  The  order  of  each  of  these  elements  is 
significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as  constrained 
by  the  sequential  flat  constraint  set  (see  table  9)  These  definitions  appear  in  ISO  8571-2.  As  additional 
constraints  FADU  identity  will  be  limited  to  'begin',  'end',  'first'  and  'next'. 

For  a  specific  file  the  number  of  data  elements  in  a  data  unit  is  given  by  the  parameters.  Each  data  element 
is  a  data  type  from  the  set  of  primitive  data  types  defined  in  the  annex  C.3  of  this  document.  Each  data 
unit  contains  the  same  data  element  types  in  the  same  order  as  all  other  data  units.  These  types  are 
determined  by  the  parameters  0  through  2. 

For  datatype  1,  the  string  length  field  of  Parameterl  specifies  the  length  of  the  value  in  octets  for  the 
INTEGER,  BIT  STRING  and  OCTET  STRING  types.  For  character-type  data  elements,  the  string-length 
indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  including  any  escape 
sequences  or  overhead  from  the  character  encoding. 

For  floating  point  numbers,  finite  form,  length-1  and  length-2  specify  the  length  in  bits  of  mantissa  and 
exponent,  respectively.  The  length-1  and  length-2  values  are  irrelevant  for  the  other  choices  of  floating  point 
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I  A.5.8      Abstract  syntactic  structure 

I  The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  file  as  defined  in  the  ASN.1 
I  module  IS08571-FADU  in  ISO  8571,  in  which  each  of  the  file  access  data  units  has  the  abstract  syntactic 
I  structure  of  NBS-AS1  as  defined  by  the  parameters. 

i 

I  A.5.9       Definition  of  transfer 

A.5.9.1        Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either 

a)  Datatypel  defined  in  table  9,  where  the  PrimType  in  the  datatype  is  given  by  the  NBS-AS1 
definition;  or 

b)  Datatype2  defined  in  table  9,  the  ASN.1  datatype  declared  as  "Data-Element"  in  the  ASN.1 
module  IS08571-FADU. 


A.5.9.2        Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is  either 

a)  one  value  of  the  ASN.1  datatype  "Datatypel,"  carrying  one  of  the  data  elements  from  the 
document.  All  values  are  transmitted  in  the  same  (but  any  )  presentation  context  established  to 
support  the  abstract  syntax  name  "asnamel "  or 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the  same  (but  any)  presentation  context 
established  to  support  the  abstract  syntax  name  "asname2". 

NOTES 

1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used,  where 
the  above  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 

Boundaries  between  presentation  data  values  in  the  same  presentation  context,  and  boundaries  between 
P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  carry  no 
semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document  with 
any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 
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A.5.9.3        Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of  types 
a)  and  b)  is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the  hierarchical 
structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO  8571  -2. 


A.5.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules  named 
in  table  9  for  all  presentation  data  values  transferred.  Implementation  may  optionally  support  other  named 
transfer  syntaxes. 


A.5.11      ASE  specific  specifications  for  FTAM 


A.5.1 1 .1       Simplification  and  relaxation  pi^(^ur^rSlmpific^^ 
Structural  oimplifioation  loooo  information. 
This  structurs^  ^rt»pllf  Icatlon  loses  informatior*- 

The  document  type  NBS-6  may  be  simplified  to  the  document  type  FTAM-3  (allowed  only  when  reading  the 
file).  The  octet  representation  of  the  transferred  data  is  unpredictable.  It  will  usually  correspond  to  the  data  j 
values  as  stored  in  the  local  Real  Filestore  of  the  Responder. 


A.5.1 1 .2      Access  context  selection 

A  document  of  type  NBS-6  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the  sequential 
flat  constraint  set.  The  presentation  data  units  transferred  in  each  case  are  those  derived  from  the 
structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


A.5.1 1.3       The  INSERT  operation 

When  the  <INSERT>  operation  is  applied  at  the  end  of  flie,  the  transferred  material  shall  be  the  series  of 
FADUs  which  would  be  generated  by  reading  any  NBS-6  document  with  the  same  parameter  values  in 
access  context  FA. 
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Table  10  -  Information  objects  In  NBS-7 


document  type  name 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 
random-file(7)} 

"NBS-7  FTAM  random  access  file" 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2) 
nbs-as1(1)} 

"NBS  abstract  syntax  AS1" 

{iso  standard  8571  abstract-syntax(2)  ftam-  fadu(2)} 
"FTAM  FADU" 

transfer  syntax  names: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  Encoding  of  a  single  ASN.1  type" 

parameter  syntax: 

PARAMETERS  ::=  SEQUENCE  OF  CHOICE  {ParameterO.  Parameterl,  Parameter2} 
ParameterO  ::  =  [0]  INTEGER  {univer-time  (23), 

gen-time  (24), 

boolean  (1), 

null  (5)  } 

Parameterl  ::=  [1]  SEQUENCE  { 

universal-class-number-1  INTEGER  {  int  (2), 

bit  (3), 
ia5  (22), 
graphic  (25), 
general  (27), 
octet  (4)}, 

string-length  INTEGER  } 
Parameter2  ::=  [2]  SEQUENCE  { 

private-class-number  INTEGER  {float  (0)}, 
length-1  INTEGER, 
length-2     INTEGER  } 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  identified-organization  oiw(14)  ftamsig(5)  constraint-set(4) 

nbs  ordered-flat(l)} 

"NBS  ordered  flat  constraint  set" 

file  contents: 

Datatypel  ::  = 

PrimType  - 

-  ac  defined  in  annex  C.3  NiSSsiVSl 

Datatype2  ::  = 

CHOICE 

{  Node-Descriptor-Data-Element, 
Enter-Subtree-Data-Element  } 
Exit-Subtree-Data-Element  } 
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=  A.6.3 


Scope  and  field  of  application 


^  The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  by  FTAM. 
i  j  NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 


A.6.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer,  Access  and 
Management 


A.6.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 


A.6.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 


A.6.7       Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units. ,  each  of  Each  FADU  contains  precisely 
zero  or  me  data  unit  which  consists  of  zero,  one  or  more  data  elements.  The  order  of  each  of  these 
elements  is  significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as  constrained 
by  the  NBS-ordered-flat  constraint  set  (see  table  10).  These  definitions  appear  in  annex  B.2  of  this 
document. 

For  a  specific  file  the  number  of  data  elements  in  a  data  unit  is  given  by  the  parameters.  Each  data  element 
is  a  data  type  from  the  set  of  primitive  data  types  defined  in  the  annex  C.3  of  this  document.  Each  data 
unit  contains  the  same  data  element  types  in  the  same  order  as  all  other  data  units.  These  types  are 
determined  by  the  parameters  0  through  2. 

For  datatype  1^  the  string  length  field  of  Parameterl  specifies  the  length  of  the  value  in  octets  for  the 
INT  EG  EPi,  BIT  STR I N  G  and  OCTET  STRING  types.  For  character-type  data  elements,  the  string-length 
indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  including  any  escape 
sequences  or  overhead  from  the  character  encoding. 


For  floating  point  numbers,  finite  form,  length-1  and  length-2  specify  the  length  in  bits  of  mantissa  and 
exponent,  respectively.  The  length-1  and  length-2  values  are  irrelevant  for  the  other  choices  of  floating  point 
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numbers. 


A.6.8       Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  file  as  defined  in  the  ASN.1 
module  IS08571-FADU  in  ISO  8571,  in  which  each  of  the  file  access  data  units  has  the  abstract  syntactic 
structure  of  NBS-AS1  as  defined  by  the  parameters. 


A.6.9       Definition  of  transfer 

A.6.9.1        Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either: 


a)  Datatypel  defined  in  table  10,  where  the  PrimType  in  the  datatype  is  given  by  the  NBS-AS1 
definition; 

b)  Datatype2  defined  in  table  10,  the  ASN.1  datatype  declared  as  "Data-Element"  in  the  ASN.1 
module  IS08571-FADU. 


A.6.9.2        Presentation  data  values 


The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is  either 

a)  one  value  of  the  ASN.1  datatype  "Datatypel,"  carrying  one  of  the  data  elements  from  the 
document.  All  values  are  transmitted  in  the  same  (but  any  )  presentation  context  dofinod 
estali^tshed  to  support  the  abstract  syntax  name  "asnamel "; 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the  same  (but  any)  presentation  context 
dofinod  established  to  support  the  abstract  syntax  name  "asname2". 

NOTES 

1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used,  where 
the  above  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 

Boundaries  between  presentation  data  values  in  the  same  presentation  context,  and  boundaries  between 
P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  carry  no 
semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document  with 
any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 
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A.6.9.3 


Sequence  of  presentation  data  values 


I  The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of  types 
a)  and  b)  is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the  hierarchical 
structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO  8571  -2. 


A.6.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules  named 
i  in  table  10  for  all  presentation  data  values  transferred.  Implementation  may  optionally  support  other  named 
transfer  syntaxes. 

j  A.6.1 1      ASE  specific  specifications  for  FTAM 


A.6.1 1 .1       Simplification  and  relaxation  Structural  simplification 


'  Structural  simplification  loses  information. 
This  s&ructural  simplification  loses  Informai^n. 

The  document  type  NBS-7  may  be  accessed  as  a  document  type  FTAM-3  (allowed  only  when  reading  the 
!i  file)  by  specifying  document  type  FTAM-3  in  the  <  contents  type>  parameter  in  <F-OPEN  request  >,  and 
I  limiting  access  context  to  UA  on  F-READ. 

ij 

'  The  octet  representation  of  the  transferred  data  is  unpredictable.  It  will  usually  correspond  to  the  data 
values  as  stored  in  the  local  Real  Filestore  of  the  Responder. 

!  A  document  of  type  NBS-7  can  be  accessed  as  a  document  of  type  NBS-6  (allowed  only  when  reading  the 
'  file)  by  specifying  document  type  NBS-6  with  appropriate  data  type  parameters  in  the  <  contents  type> 
j  parameter  on  the  <F-OPEN  request  >. 


i  A.6.1 1.2       Access  context  selection 

i 

A  document  of  type  NBS-7  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the  NBS  ordered 
I  flat  constraint  set.  The  presentation  data  units  transferred  in  each  case  are  those  derived  from  the 
j  structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


When  the  <  INSERT  >  operation  is  applied  at  the  end  of  file,  the  transferred  material  shall  be  the  series  of 
FADUs  which  would  be  generated  by  reading  any  NBS-7  document  with  the  same  parameter  values  in 
access  context  FA. 


A.6.11.3 


The  INSERT  operation 
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Table  11  -  Information  objects  in  NBS-8 


documsnt  type  nam6 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 

indexed-file(8)} 

"NBS-8  FTAM  indexed  file" 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract  syntax(2) 
nbs-as1(1)} 

"NBS  abstract  syntax  AS1" 

{iso  standard  8571  abstract-syntax(2)  ftam-  fadu(2)} 
"FTAM  FADU" 

transfer  syntax  names: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  Encoding  of  a  single  ASN.1  type" 

parameter  syntax: 

PARAMETERS  ::=  SEQUENCE           {DataTypes,  KeyType,  KeyPosition} 

DataTypes  ::=  SEQUENCE  OF  CHOICE  {ParameterO,  Parameterl,  Parameter2} 

KeyType     ::=  CHOICE  {ParameterO,  Parameterl,  Parameter2} 

-  ParameterO,  Parameterl ,  Parameter2,  as  defined  for  the 
~  document  types  NBS-6,  NBS-7 

KeyPosition::  =  INTEGER 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set(4)  ordered-flat(3)  } 
"FTAM  ordered  flat  constraint  set" 

file  contents: 

Datatypel  ::=  PrimType  --  as  defined  in  annex  C.3  NBS-AS1 

Datatype2  ::=  CHOICE  {Node-Descriptor-Data-Element, 

Enter-Subtree-Data-Element, 
Exit-Subtree-Data-Element  } 

Datatypes  ::=  Primtype  ~  as  defined  by  the  NBS  abstract  syntax  AS1 

A.7.3       Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  using  FTAM. 
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NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 


A.7.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -File  Transfer,  Access  and 
Management 


A.7.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  In  ISO 
8571-1. 


A.7.6  Abbreviations 

RAIVI  File  Transfer,  Access  and  Management 


A.7.7       Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units.  Each  FADU  contains  precisely  one  data 
unit  which  consists  of  zero,  one  or  more  data  elements.  The  order  of  each  of  these  elements  Is  significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as  constrained 
by  the  FTAM  ordered  flat  constraint  set  (see  table  11).  These  definitions  appear  in  ISO  8571-2. 

The  following  additional  requirements  are  specified  for  the  use  of  the  ordered  flat  constraint  set: 

The  FADU  Identities  'first',  'last',  and  'node  number'  are  not  required  for  conformant  implementations 

The  Identities  'next'  and  'previous'  are  allowed  for  all  FADUs 

Each  data  element  Is  a  data  type  from  the  set  of  primitive  data  types  defined  In  annex  0.3  of  this  document. 
Each  data  unit  contains  the  same  data  element  types  In  the  same  order  as  all  other  data  units.  These  types 
and  their  respective  maximum  lengths  are  defined  by  the  <DataTypes>  parameter. 

For  Datatypel  and  Datatypes,  the  string  length  field  of  Parameterl  specifies  the  length  of  the  value  in  octets 
for  the  INTEGER,  BIT  STRING  and  OCTET  STRING  types.  For  character-type  data  elements,  the  string- 
length  Indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  including  any  escape 
sequences  or  overhead  from  the  character  encoding. 

For  floating  point  numbers,  finite  form,  length-1  and  length-2  specify  the  length  In  bits  of  mantissa  and 
exponent,  respectively.  The  length-1  and  length-2  values  are  Irrelevant  for  the  other  choices  of  floating 
point  numbers. 
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Each  data  unit  in  tlie  file  lias  a  key  associated  with  it,  which  is  the  user-coded  form  of  Node-Name  whiet) 
io  tho  UGor  oodod  form  of  NodoNamo.  The  key  of  each  data  unit  is  of  the  same  data  type  as  the  key  of  all  t 
other  data  units  in  the  file  and  is  a  single  data  element  from  the  set  of  primitive  data  types  defined  in  annex 
C.3  . 

The  type  and  length  of  the  key  are  defined  by  the  <KeyType>  parameter. 

The  primitive  data  types  and  minimum  size  ranges  of  each  unit  which  an  implementation  must  accept  as 
a  key  value  are  given  in  the  following  table  12. 


Table  12  -  Datatypes  for  keys 


Key  Type 

Minimum  Range 
(octets) 

Order 

ASN.1  INTEGER 

(1-2) 

increasing  numeric  value 

ASN.1  IA5String 

(1-16) 

lexical  order 

ASN.1  GraphicString 

(1-16) 

lexical  order 

ASN.1  GeneralString 

(1-16) 

lexical  order 

ASN.1  OCTET  STRING 

(1-16) 

increasing  value 

ASN.1  GeneralizedTime 

increasing  time  value 

ASN.1  UniversalTime 

increasing  time  value 

NBS-AS1 

FloatingPointNumber 

increasing  numeric  value 

The  position  of  the  key  in  the  data  unit  is  specified  by  the  <  KeyPosition>  parameter. 
KeyPosition  =  0  implies  the  key  is  not  part  of  the  data 
position  >  0  specifies  the  actual  data  element  in  the  data  unit. 

A.7.8       Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  file  as  defined  in  the  ASN.1 
module  IS08571-FADU  in  ISO  8571,  in  which  each  of  the  file  access  data  units  has  the  abstract  syntactic 
structure  of  NBS-AS1  as  defined  by  the  parameters. 
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A.7.9 


Definition  of  transfer 


A.7.9.1 


Datatype  definitions 


The  file  consists  of  data  values  which  are  of  either 

a)  Datatypel  defined  in  table  11,  where  the  PrimType  in  the  datatype  is  given  by  the  NBS-AS1 
definition;  or 

b)  Datatype2  defined  in  table  11,  the  ASN.1  datatype  declared  as  "Data-Element"  in  the  ASN.1 
module  IS08571-FADU;  or 

c)  Datatypes  defined  in  table  1 1 ,  which  specifies  the  user-coded  form  of  the  Node-Name  in  the 
FTAM  FADU  abstract  syntax,  where  user-coded  is  defined  as  EXTERNAL. 


The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is  either 

a)  one  value  of  the  ASN.1  datatype  "Datatypel,"  carrying  one  of  the  data  elements  from  the 
document.  All  values  are  transmitted  in  the  same  (but  any)  presentation  context  established  to 
support  the  abstract  syntax  name  "asnamel "  or 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the  same  (but  any)  presentation  context 
established  to  support  the  abstract  syntax  name  "asname2";  m 


c)  a  value  of  ^'Datatypes*  carrylntgi  a  k«y.  All  values  are  transmitted  in  the  same  (but  an^ 
presentalioh  cc^itext  established  to  support  the  abstract  syntax  name  "asnamet". 


1  specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used,  where 
the  above  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 

Boundaries  between  presentation  data  values  in  the  same  presentation  context,  and  boundaries  between 
P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  carry  no 
semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document  with 
any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 


A.7.9.3        Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of  types 
a)  and  b)  is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the  hierarchical 


Presentation  data  values 


NOTES 
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structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO  8571-2. 


A.7.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules  named 
in  table  1 1  for  all  presentation  data  values  transferred.  Implementation  may  optionally  support  other  named 
transfer  syntaxes. 


A.7.11      ASE  specific  specifications  for  FTAM 


A.7.11.1       Structural  simplification 

This  simplification  loses  information. 

The  document  type  NBS-8  may  be  accessed  as  a  document  type  FTAM-3  (allowed  only  when  reading  the 
file)  by  specifying  document  type  FTAM-3  in  the  <  contents  type>  parameter  in  <F-OPEN  request  >,  and 
limiting  access  context  to  UA  on  F-READ. 

The  octet  representation  of  the  transferred  data  is  unpredictable.  It  will  usually  correspond  to  the  data 
values  as  stored  in  the  local  Real  Filestore  of  the  Responder. 

A  document  of  type  NBS-8  can  be  accessed  as  a  document  of  type  NBS-6  (allowed  only  when  reading  the 
file)  by  specifying  document  type  NBS-6  with  appropriate  data  type  parameters  in  the  < contents  type> 
parameter  on  the  <F-OPEN  request  >.  The  traversal  order  of  the  FADUs  must  be  maintained. 

NOTE  -  The  traversal  order  is  as  reading  the  file  as  NBS-8  in  key  order. 


A.7.1 1 .2      Access  context  selection 

A  document  of  type  NBS-8  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the  FTAM  ordered 
flat  constraint  set.  The  presentation  data  units  transferred  in  each  case  are  those  derived  from  the 
structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


A.7.11 .3       Thie  INSERT  operation 

When  the  <  INSERT>  operation  is  applied  the  transferred  material  shall  be  the  series  of  FADUs  which  would 
be  generated  by  reading  any  NBS-8  document  with  the  same  parameter  values  in  access  context  FA. 

The  insertion  of  a  new  FADU  after  an  already  existing  FADU  will  be  indicated  via  a  diagnostic  on  TRANSFER- 
END. 
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A.7.1 1 .4      The  EXTEND  operation 

This  operation  is  excluded  for  use  with  this  document  type. 

A.8     NBS-9  File  directory  file 
A.8.1       Entry  Number:  NBS-9 
A.8.2       Information  objects 
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Table  13 

-  Information  obiects  in  NBS-9 

document  type  name 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 

Tiie-uir©ciory^yj  f 

"NBS-9  FTAM  file  directory  file" 

abstract  syntax  names: 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2) 

nbs-as2(2)} 

"NBS  file  directory  entry  abstract  syntax" 

transfer  syntax  names: 

parameter  syntax 

PARAMETERS  ::=  [0]  IMPLICIT  BIT  STRING  { 

-  Kernel  group 

read-filename  (0), 

read-pernnitted-actions  (1), 

read-contents-type  (2), 

-  Storage  group 

read-storage-account  (3), 

read-date-and-ti  me-of-creation  (4) , 

read-date-and-time-of-last-modification  (5), 

read-date-and-time-of-last-read-access  (6), 

read-date-and-time-of-last-attribute-modification(7), 

read-identity-of-creator  (8), 

read-identity-of-last-modifier  (9), 

read-identity-of-last-reader  (10), 

read-identity-of-last-attribute-modifier  (11), 

read-file-availability  (12), 

read-filesize  (13), 

read-future-filesize  (14), 

-  Security  group 

read-access-control  (15), 

read-legal-qualifications  (16), 

-  Private  group 

read-private-use  (17)  } 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 

"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set(4)  unstructured(l)} 

"FTAM  unstructured  constraint  set" 

File  contents: 

Datatypel  ::=  FileDirectoryEntry 

-As  defined  by  NBS-AS2  in  annex  C, 

-C.4  of  this  document 
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A.8.3       Scope  and  field  of  application 

This  document  defines  the  contents  of  a  file  for  transfer  (not  for  storage)  using  FTAM. 


A.8.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -File  Transfer,  Access  and 
Management. 


A.8.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1 


A.8.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management. 


A.8.7       Document  Semantics 

The  document  consists  of  one  file  access  data  unit,  which  consists  only  of  zero,  one  or  more  data  elements 
of  type  <FileDirectoryEntry>  (defined  in  NBS-AS2). 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as  constrained 
by  the  unstructured  constraint  set.  These  definitions  appear  in  ISO  8571-1. 

The  parameter  of  the  document  type  is  used  on  <  F-OPEN  request  >  to  specify  the  desired  attributes  of  each 
of  the  files  on  the  Filestore,  when  reading  the  document. 


A.8.8       Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  series  of  file  directory  entries,  each  of  which  is  defined 
by  the  <FileDirectoryEntry>  definition  in  NBS-AS2. 

Additional  constraints  are  defined  for  this  document  type:  File  access  actions  are  restricted  to  Read.  File- 
directory  files  may  not  be  Written  or  Modified  (except  as  a  side  effect  of  actions  performed  on  individual  files 
contained  within  a  file  directory). 
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A.8.9 


Definition  of  transfer 


A.8.9.1 


Datatype  definition 


The  file  consists  of  zero  or  more  values  of  Datatypel  defined  in  table  13. 


A.8.9.2 


Presentation  data  values 


The  document  is  transferred  as  a  series  of  presentation  data  values.  Each  presentation  data  value  shall 
consist  of  one  value  of  the  ASN.1  data  type  "Datatypel,"  carrying  one  of  the  file  directory  entries  from  the 
document. 

All  values  are  transmitted  in  the  same  (but  any)  presentation  context  established  to  support  the  abstract 
syntax  name  "asnamel"  declared  in  table  13. 


A.8.9.3        Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  is  the  same  as  the  sequence  of  file  directory  entries  within  the 
Data  Unit  in  the  file. 


A.8.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules  named 
in  table  13  for  all  presentation  data  values  transferred.  Implementations  shall  optionally  support  other  named 
transfer  syntaxes. 


A.8.11      ASE  specific  specifications  for  FTAM 

Relaxation  is  allowed  to  any  bitstring  combination  of  the  document  type  parameter. 
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Annex  B  (normative)  

Constraint  Sets 

1  B.1      NBS  Ordered  ordered  flat  constraint  set 

This  object  with  Object  Identifier 

{iso  identifled-organization  icd(9999)  organization-code(l)  constraint-set(4)  nbs-ordered-flat(l)} 

jj  was  withdrawn  on  March  16.  1990.  It  was  replaced  with  the  object  NBS  ordered  flat  constraint  set  with  the 
'  Object  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  constraint-set (4)  nbs-ordered-flat(l)} 
defined  in  part  9,  B.2. 

j 
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B.2      NBS  Ordered  g|difii  flat  constraint  set  definition 
B.2.1       Field  of  application 

The  NBS-ordered  flat  constraint  set  applies  to  files  which  are  structured  into  a  sequence  of  individual  FADUs 
and  to  which  access  may  be  made  on  an  FADU  basis  by  position  in  the  sequence. 

B.2.2       Basic  constraints 


64 


Part  9  -  FTAM  Phase  2 


March  1991  (Stable) 


Table  14  -  Basic  constraints  for  NBS  Ordered  (xrdered  flat 


I'IIm'vJ         UCI           IICIl            loll  dll  H  OOl 

^Oiloirallli  oci  luciiiiiioi 

•fi^n  iHpntififiH-nrn?ini7?itir»n  ri\\/jlAA\  fl"amcin/'-i\ 

^lO^  lUd  llllloU  \Ji  ^Cll  II^ClUwl  1  WIWI  1  *tJ    lldl  1  Idl^^O  J 

constraint-set(4)  nbs-ordered-flat(1 )} 

Node  name 

None 

File  access  actions 

Locate,  Read,  Insert,  Erase,  Replace 

Qualified  action 

None 

AVQiiauiG  access  cuniexis 

HA  FA  1  lA 
riM,  nrt, 

Rnnt  nnrlfl  withniit  an  a^^opij^tpH  Hati^  iinit 

FIWWl   1  l^i^VJO  Will  IWUI  Ol  1  ClOOwWICIl%3U  UdLO  Ul  III 

Location  after  open 

Root  node 

Beginning  of  file 

Root  node 

End  of  file 

No  node  selected;  'previous'  gives  last  node  in  traversal  sequence, 
'current'and  'next'  give  an  error. 

RoaH  u/KhIa  flip 

Rp^^H  in  ?ippp<5^  pnntpyt  FA  nr  1 JA  with  FAHI 1  iripntitv  nf  'hpnin* 

Write  whole  file  (append) 
Write  whole  file  (replace) 

Transfer  the  series  of  leaf  FADUs  which  would  be  generated  by  reading 
the  whole  file  in  access  context  FA;  perform  the  transfer  with  an  FADU 
identity  of  'end'  and  a  file  access  action  of  'insert'. 

Transfer  the  series  of  leaf  FADUs  which  would  be  generated  by  reading 
the  whole  file  in  access-context  HA;  perform  the  transfer  with  FADU 
identity  'begin'  and  file  action  of  'replace'. 

B.2.3       Structural  constraints 

The  root  node  shall  not  have  an  associated  data  unit;  all  children  of  the  root  node  shall  be  leaf  nodes  and 
may  have  an  associated  data  unit;  all  arcs  from  the  root  node  shall  be  of  length  one. 


B.2.4       Action  constraints 

Insert:  The  <  Insert >  action  is  allowed  only  at  the  end  of  file.If  the  FADU  identity  is  'end'  the  new  node  is 
inserted  following  all  existing  nodes  in  the  file.  If  the  FADU  identity  is  'node  number',  the  number 
must  be  at  least  one  greater  than  the  node  number  of  the  last  existing  node.  Any  nodes  between 
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the  last  existing  node  and  the  new  node  are  empty,  I.e.,  nodes  without  data.  If  the  FADU  Identity 
is  a  'node  number'  not  greater  than  that  of  the  last  existing  node,  an  error  will  occur.  The  location 
following  <  insert  >  is  'end'. 

Erase:  The  Erase  action  is  only  allowed  at  the  root  node  to  empty  the  file,  with  FADU  identity  of  'begin'. 
The  result  is  a  solitary  root  node  without  an  associated  data  unit. 

NOTE  -  It  is  the  intention  when  using  this  constraint  set  to  allow  for  emptying  an  FADU,  i.e.,  leaving  an  FADU 
with  a  DU  of  data  length  0  (or  without  a  DU);  afterwards  data  may  be  reinserted  into  this  hole.  In  order  to 
•  empty  an  FADU,  the  <  Replace >  operation  may  be  used  with  new  data  of  length  zero  (or  with  an  FADU  whose 
<data  exists>  bit  is  set  to  'false'  and  no  DU).  Refilling  the  hole  is  accomplished  by  a  <Replace>  operation 
with  the  new  DU  (or  with  the  new  FADU,  whose  <data  exists>  bit  is  set  to  'true'  and  the  new  DU). 


B.2.5       Identity  constraints 

The  FADU  identity  associated  with  the  file  action  shall  be  one  of  the  identities  'begin',  'end',  'first',  'last', 
'current',  'next',  'previous'  or  a  'node  number'  greater  than  or  equal  to  one.  The  actions  with  which  these 
identities  can  be  used  are  given  in  the  following  table. 


Table  15  -  Identity  constraints  in  NBS  Ordered  icurd^riec)  flat 


Action 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node  No. 

Locate 

valid 

valid 

valid 

valid 

valid 

valid 

valid 

valid 

Read 

whole 

leaf 

leaf 

leaf 

leaf 

leaf 

leaf 

Insert 

leaf 

leaf 

Erase 

whole 

Replace 

whole 

leaf 

leaf 

leaf 

leaf 

leaf 

leaf 
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Annex  C  (normative)  

Abstract  Syntaxes 

C.1     Abstract  Syntax  NBS-AS1 

;  This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(l)  abstract-syntax(2)  nbs-as1(1)} 

was  withdrawn  on  March  16, 1990.  It  was  replaced  with  the  object  Abstract  syntax  NBS-AS1  with  the  Object 
I  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-asl(l)} 
i  defined  in  part  9,  C.3. 

C.2     Abstract  Syntax  NBS-AS2 

}  This  object  with  Object  Identifier 

^  {iso  identified-organization  icd(9999)  organization-code(l)  abstract-syntax(2)  nbs-as2(2)} 

ii 

was  withdrawn  on  March  1 6, 1 990.  It  was  replaced  with  the  object  Abstract  syntax  NBS-AS2  with  the  Object 
Ii  identifier 

||  {iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax (2)  nbs-as2(2)} 
!  defined  in  part  9,  0.4. 

i  C.3     Abstract  Syntax  NBS-AS1  definition 

'  Abstract  syntax  name:  {iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-asl(l)} 
I  "NBS  abstract  syntax  AS1" 

'  This  is  an  abstract  syntax  for  the  set  of  presentation  data  values,  each  of  which  is  a  value  of  the  ASN.1  type 
NBS-ASI.PrimType 

I 

j 

i 
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NBS-AS1  DEFINITIONS  :: 
BEGIN 

PrimType  ::=  CHOICE 


{ 


INTEGER, 


BIT  STRING, 
BOOLEAN. 
lASString, 
GraphicString, 
GeneralString, 
OCTET  STRING, 
UTCTIme, 
GenerallzedTlme, 
NULL, 

FloatingPointNumber }  j 

The  support  for  lASString  is  the  ISO  646,  IRV  GO  | 
character  set  and  the  ISO  646,  IRV  CO  set 
The  minimum  level  of  support  for  GraphicString  is 
the  ISO  646,  IRV  GO  character  set  and  the  8859-1 
GO  and  Gl  sets.  , 
The  minimum  level  of  support  for  GeneralString  is 
the  ISO  646,  IRV  GO  character  set  and  the  8859-1 
GO  and  Gl  character  sets,  and  ISO  646,  IRV  CO  set. 


first  bit  must  be  1 
exponent  INTEGER}, 
infinity  [1]  IMPLICIT  Sign, 
signalling-nan  [2]  IMPLICIT  NaN, 
quiet-nan  [3]  IMPLICIT  NaN, 
zero  [4]  IMPLICIT  NULL  } 


FloatingPointNumber  ::  = 


[PRIVATE  0]      CHOICE  { 
finite  [0]  IMPLICIT  SEOUENCE 
Sign, 

mantissa  BIT  STRING, 


{ 


Sign     ::=  INTEGER  {  positive  (0),  negative  (1)  } 

NaN     ::=  INTEGER 

END 


For  this  abstract  syntax  the  following  transfer  syntax  can  be  used 


{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 


"Basic  Encoding  of  a  single  ASN.1  type' 
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NOTES 

1  The  mantissa  is  a  number  in  the  range  (1/2  <mantissa<1). 

2  The  value  is  equal  to  mantissa  *  2  «"p°"«"'. 

3  The  first  bit  in  the  mantissa  is  most  significant. 

4  See  IEEE  754  for  definitions  of  terminology,  such  as  NaN. 

5  A  minimum  length  range  (in  bits)  is  required  for  the  components  of  <FloatingPointNumber>,  as  follows: 
mantissa  1-23  bits,  and  exponent  0-8  bits. 

C.4     Abstract  Syntax  NBS-AS2  definition 

Abstract  syntax  name:   {  iso  identlfied-organlzation  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-as2(2)  } 

"NBS  file  directory  entry  abstract  syntax" 

This  is  an  abstract  syntax  for  the  set  of  presentation  data  values,  each  of  which  is  a  value  of  the  ASN.1  Type 
NBS-AS2.FileDirectoryEntry. 

NBS-AS2  DEFINITIONS  ::  = 
BEGIN 

FileDirectoryEntry  ::  =  [PRIVATE  2]  Read-Attributes 
Read-Attributes  ::  =  IS08571  -FTAM.Read-Attributes 
END 

For  this  abstract  syntax  the  following  transfer  syntax  will  be  used 
{  joint-iso-ccitt  asn1(1)  basic-encoding(l)  } 
"Basic  Encoding  of  a  single  ASN.1  type" 

C.5     Abstract  Syntax  "FTAM  unstructured  text  abstract  syntax" 

This  abstract  syntax  is  defined  as  DataTypel  (File  Contents)  in  table  19  of  ISO  8571-2,  annex  B. 
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Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  File  Transfer,  Access  and  j 

Management  Special  Interest  Group  (FTAM  SIG)  of  the  National  Institute  of  Standards  and  Technology  j 

(NIST)  Workshop  for  Implementors  of  Open  Systems  Interconnection  (OSI).  See  Procedures  Manual  for  ] 
Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces  | 

the  previously  existing  chapter  on  this  subject.  There  is  no  significant  technical  change  from  this  text  as  j 

previously  given.  References  to  Part  9  are  made  in  this  part.  1 


Five  Normative  Annexes  are  included.  Three  alignment  errata  were  approved  in  December  1990,  as  follows: 
a)  add  requirement  to  conform  to  amendments  and  corrigenda; 


b)  change  support  level  of  erase  in  requested  access  and  processing  mode; 

c)  change  support  level  of  concurrency  control  in  F-select,  F-create,  and  F-open.  j 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change  j 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as  I 


shaded. 
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Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  File  Transfer,  Access  and 
Management  Special  Interest  Group  (FTAM  SIG)  of  the  National  Institute  of  Standards  and  Technology 
(NIST)  Workshop  for  Implementors  of  Open  Systems  Interconnection  (OSI).  See  Procedures  Manual  for 
Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject.  There  is  no  significant  technical  change  from  this  text  as 
previously  given.  References  to  Part  9  are  made  in  this  part. 

Five  Normative  Annexes  are  included.  Three  alignment  errata  were  approved  in  December  1990,  as  follows: 

-  add  requirement  to  conform  to  amendments  and  corrigenda; 

-  change  support  level  of  erase  in  requested  access  and  processing  mode; 

-  change  support  level  of  concurrency  control  in  F-select,  F-create,  and  F-open. 
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Part  10  -  ISO  File  Transfer,  Access  and  Management  Phase  3 


Editor's  Note  -  The  "NBS"  designation  remains  in  effect  for  document  types,  abstract  syntaxes,  and  constraint 
sets  defined  in  all  FTAM  agreements  up  to  1  /1/89.  After  1  /1  /89,  any  new  functionality  references  the  "NIST" 
designation.  This  is  to  reflect  the  change  in  identifying  organization  from  "NBS"  to  "NIST." 


0  Introduction 

This  clause  contains  Implementors  Agreements  based  on  ISO  8571  File  Transfer,  Access  and  Management, 
i  These  Agreements  define  enhancements  to  the  Stable  FTAM  Implementation  Agreements  for  OSI  Protocols, 
I  Version  1,  Edition  1,  December  1987  (FTAM  Phase  2  Agreements,  NBS  500-150),  including  all  their 
I  subsequent  Errata  changes  through  Version  4,  Edition  1  (NIST  Special  Publication  500-183,  this  document 


Therefore  It  is  assumed  that  the  reader  is  familiar  both  with  the  contents  of  the  base  standard  ISO  8571  and 
its  underlying  layers,  and  also  with  the  above-mentioned  NIST  FTAM  Phase  2  specifications. 

Phase  2  Agreements  define  six  Implementation  Profiles  which  are  T1,  T2,  T3,  A1,  A2,  and  Ml.  In  order  to 
avoid  ambiguity  when  referring  to  these  Implementation  Profiles  the  above  designations  will  apply  only  to 
Phase  2  functionality,  references  to  Phase  3  enhanced  Implementation  Profiles  will  be  by  the  addition  of  a 
'.3',  i.e..  T1.3,  T2.3,  T3.3,  A1.3,  A2.3,  and  Ml. 3. 

The  following  clauses  specify  the  functionality  of  NIST  OIW  FTAM  Phase  3: 

IliClauses  1  and  8  specify  the  technical  details  of  FTAM  Phase  3  which  are  defined  in  addition  to 
the  functionality  of  FTAM  Phase  2.  Included  is  also  a  status  overview  regarding  statements  on 
Phase  2/Phase  3  compatibility  and  interworking; 

iHlAnnex  A  is  a  Profile  Requirements  List  for  the  Implementation  Profiles  T1 .3,  T2.3,  A1 .3  and  Ml  .3, 
summarizing  all  features  of  FTAM  Phase  3,  including  those  of  FTAM  Phase  2.  This  Profile 
Requirements  List  is  fully  based  on  the  FTAM  PICS  Proforma  ISO  8571-5; 

c)  Annex  B  is  an  index  of  Object  Identifiers.  It  is  the  official  NIST  OIW  Register  of  NIST  OIW 
defined  FTAM  objects.  It  contains  the  Object  Descriptors  and  Object  Identifiers  for  these  objects, 
Including  a  reference  to  the  clause  in  the  NIST  OIW  Stable  Agreements  where  the  respective  object 
is  being  defined; 

HIIAnnexes  C,  D,  and  E  provide  definitions  for  additional  document  types,  constraint  sets  and 
abstract  syntaxes; 
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1  Scope 

These  Phase  3  Agreements  specify  additional  functionality  to  the  FTAM  Phase  2  Agreements.  These 
additional  functions  include: 

Further  specifications  of  document  types; 

Specification  for  Restart  Data  Transfer  and  Recovery  functional  units; 

Specification  of  FADU  Locking  functional  unit; 

More  details  on  Access  Control  and  Concurrency  Control. 

All  Phase  2  systems  are  upward  compatible  to  a  Phase  3  system  and  can  therefore  interwork  with  it,  if  the 
additional  functions  are  negotiated  out  (e.g.,  use  of  Recovery)  or  not  used  for  the  interconnection  (e.g., 
additional  features  for  document  types). 


2     Normative  References 

Ameixlments  and  corrigenda  to  the  base  starKiards  referenced:  See  arwiex  G  Jor  a  oomji^^e  list  of  these 

ISO  8571-1:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  1:  General  Introduction 

ISO  8571-2:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  2:  Virtual  Filestore  Definition 

ISO  8571-3:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  3:  The  File  Service  Definition 

ISO  8571-4:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  4:  File  Protocol  Specification 
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3  Status 

These  FTAM  Phase  3  Agreements  were  completed  December  15,  1989.  No  further  enhancements  will  be 
made  to  this  version  (see  also  next  clause  ERRATA). 

The  following  tables  summarize  the  functions  and  features  which  are  defined  for  FTAM  Phase  3  In  addition 
to  the  FTAM  Phase  2  specifications.  They  also  state  the  degree  of  possible  interworking  and  the  backward 
compatibility. 


Table  1^  -  Phase  2/Phase  3  Interworking 


Additional  requirements  in  FTAM  phase  3 

Backv^ard  compatibility  to 
FTAM  phase  2 

FTAM-1 :  GraphicString.VisibleString 
FTAM-2:  VisibleString 
concurrency-control  parameter  for  Initiator 
create-password  parameter  for  Initiator 

Profile  M1.3:  Requires  support  of 

(1)  -T  service  class  including  Limited  File 
Management  FU,  Enhanced  FM  FU; 

TM  service  class  including  Enhanced  FM  FU  or 

(2)  -A  service  class  including  Limited  File 
Management  FU,  Enhanced  FM  FU 

full  backv«/ard  compatibility  if  the 
additional  features  of  Phase  3 
are  not  being  used  (character 
sets  in  FTAM-1,  -2),  or  not 
requested  by  an  Initiator 
(functional  units)  or  not 
required  by  a  Responder 
(parameters)  not  requested  by 
an  Initiator  (functional  units) 
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Table  1(b>  -  Phase  2/Phase  3  Interworking  (continued) 


Additional  optional  features  in  FTAM  phase  3 

Backvt/ard  compatibility 
to  FTAM  phase  2 

FTAM-2:  GeneralString,  lASString 
FTAM-4 

NBS-8  in  T2.3,  A1.3 

NBS-9  in  A1.3,  A2.3 

NBS-10 

NBS-11 

NBS-12 

Recovery  functional  unit 
Restart-data-transfer  functional  unit 

FADU-locking  functional  unit  and  FADU-lock  parameters  in  A1 .3,  A2.3 
Concurrencv-control  Darameters  for  ResDonder 
create-password  parameter  for  Responder 
location-field  of  access-control  element 

suggested-delay  term  of  diagnostic  parameter  supported  conditionally  on 
Recovery  functional  units 

full  backward  compatibility  if  the 
additional  features  of  Phase  3  are  not 
requested,  negotiated  out  or  not  being 
used 
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Table  1(g>  -  Phase  2/Phase  3  Interworking  (concluded) 


Relaxation  for  FTAM  phase  3 

Backward  compatibility  to  FTAM  phase 
2 

Profiles  A1 .3,  A2.3  do  not  require  transfer  service  class 

no  minimum  requirements  for  maximum-string-length  parameters  for  document 
types 

if  T  service  class  not  being  used 

if  a  Phase  3  system  stays  below  this 
minimum  requirement 

4  Errata 

Table  2  -  List  of  Errata 


No.  of 
errata 

Type 

Referenced 
document 

Clause 

Description 

CP  3/91-1 

Editorial 

NIST-SP  500-183 

All 

Update  to  ISO  style.  General 
formatting  and  error  corrections. 
Alignment  with  the  wording  of  the  ISP. 
Consistent  naming  conventions. 

CP  6/91-1 

Editorial 

NIST-SP  500-183 

8.6.1 

Previous  errata  changed  the  Profile 
Requirements  List  (PRL)  lUpport  of 
Concurrency  Control  but  not  the 
tGXtr  fmm  'W  to  "q°.  This  change 

was  not  reflected. 

A.13.9.1.2 
A.13.9.1.3 
A.13.9.1.4 

Alignment  with  the  ISP. 
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NO.  OT 

errata 

Type 

Referenced 
document 

Clause 

Description 

CP 

Tabid  4 

CP  9/91-2 

Table  5 

tor  consi$ti&ncy  with  oD16^  OiW 

9/91-2 

Table  8 

WC;*U  IUIWII:-:IWI-:-:1iMUCKiy|J(C?w 

Iprevtous  change  incompiete]. 

CP  9/91-4 

At.i2.iej 

Add  reference  lo  wwrigenda. 

Support  l0ver  from  V  to  *ni'.  Add 

ntotd  that  must  mjppor!  at  least  one 

A.12.17.5 

action,  Add  rjote^tjoutsupportiRg 
at  Jeast  one  optional  FU. 

CPsiPSl^ 

A.13.6,1 

Change  to  spelllrig  of  ASM.  t  le>d 

0-2.9.2 

descriptions 

"Structural  Simpliflcjatior^'  to 

C.2J1J 
C  x*i  1 1 1 

"Simplification^' 

CP  s/ms 

11 

Changed  "wllr  lo  *can^ 

Annex  B 

Added  Editors  notfe  of  Ihtentiort  td 

remove  object  definltlcms  when  the 

ISP  is  pubtished. 

ii 

New  annex  to  tist  corrigenda 
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5  Conformance 

In  addition  to  the  specific  requirements  specified  in  the  following  subclauses,  confornnance  to  this  Phase 
3  specification  requires 

conformance  to  ISO  8571:  1988 

conformance  to  Phase  2  FTAM,  unless  specified  otherwise  In  this  part  10. 

The  access  Profiles  A1 .3  and  A2.3  do  not  include  the  requirement  for  transferring  files  using  the  File 
Transfer  service  class. 


6  Assumptions 

FTAM  Phase  3  Agreements  specify  additional  functionality  to  the  Implementation  Profiles  T1,  T2,  T3,  A1, 
A2,  and  Ml  as  defined  in  the  FTAM  Phase  2  Agreements.  So  all  definitions  and  requirements  for  these 
Implementation  Profiles  apply  also  to  the  Phase  3  Agreements. 


7     Filestore  Agreements 


7.1      Document  Types 

In  addition  to  the  Phase  2  Document  Type  Agreements  the  document  types  FTAM-4  (see  ISO  8571-2, 
Annex  B)  and  NBS-10,  NBS-11,  NBS-12  (see  Annex  C)  are  defined  for  optional  support. 

Table  2  gives  the  support  levels  for  ail  document  types  with  respect  to  the  Implementation  Profiles. 

For  FTAM-1,  FTAM-2,  FTAM-3  and  FTAM-4  the  supported  parameter  values  for  <  universal  class 
number  >  and  <  string  significance  >,  respectively  are  listed.  Other  values  are  outside  the  scope  of  these 
Agreements.  No  restriction  or  minimum  requirement  is  defined  for  the  <  maximum  string  length  > 
parameter  of  these  document  types. 


6-1 
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Table  3(a)  -  Implementation  Profiles  and  Document  Types  -  FTAM-1  Through  FTAM-4 


Implementation 
Profile 
(Note  1) 

Document 
Type 

Universal  Class 
Number 

(Notes  1,3,4,5) 

String  Significance 

T1.3,  T2.3,  T3.3, 
A1.3,  A2.3 

FTAM-1 

GraphicString  (25) 

^variable'  'fixed' 

VisibleString  (26) 

'variable'  'fixed' 

GeneralString  (27) 

'not-significant ' 

IA5String  (22) 

'not-significant ' 

T2.3,  T3.3,  A1.3, 

FTAM-2 

GraphicString  (25) 

'not-significant ' 

VisibleString  (26) 

'not-significant ' 

[GeneralString  (27)] 

'not-significant ' 

[lASString  (22)] 

'not-significant ' 

T1.3,  T2.3,  T3.3, 
A1.3,  A2.3 

FT AM- 3 

'not-significant' 

[T2.3],  [T3.3], 
[A1.3],  [A2.3] 

FTAM-4 

'not-significant ' 

Table  3(b)  -  Implementation  Profiles  and  Document  Types  -  NBS-6  Through  NBS-11  (continued) 


Implementation  Profile 
(Note  1) 

11 

Document 

Type  1 

[T2.3],  T3.3,    [A1.3],  A2 . 3 



NBS-6 

[T2.3],  T3.3,    [A1.3],  A2 . 3 

NBS-7 

[T2.3],  T3.3,    [A1.3],  A2 . 3 

NBS-8 

[T1.3],    [T2.3],  [T3.3], 
[Al,3],  tA2.3] 

NBS-9 

[T2.3],    [T3.3],  [A1.3], 
[A2.3] 

NBS-10 

[T2.3],    [T3.3],  [A1.3], 
[A2.3] 

NBS-11 
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Table  3(c)  -  Implementation  Profiles  and  Document  Types  -  NBS-12  (concluded) 


Implementation 
profile  (Note  1) 

Document 
type 

Universal  class 
number 

Character-set  escape 
sequences  as  defined 
for  reg.  numbers 
CO      GO  G1 

String-significance 

[T2.3],  [T3.3], 

[A1.3], 

[A2.3] 

NBS-12 
See  Note  6 

lASString  [22] 

(parameter  absent) 

'variable'  'fixed' 

GraphicString  [25] 

(parameter  absent) 

'variable'  'fixed' 

GraphicString  [25] 

6  100 

'variable'  'fixed' 

VisibleString  [26] 

(parameter  absent) 

'variable'  'fixed' 

GeneralString  [27] 

(parameter  absent) 

'variable'  'fixed' 

GeneralString  [27] 

1        6  100 

'variable'  'fixed' 

NOTES 

1  Brackets  around  a  Profile  designator  or  a  parameter  value  indicate  tiiat  tlie  respective  document  type  or 
parameter  value  is  optionally  supported  in  this  Implementation  Profile. 

2  The  support  level  for  document  types  in  Implementation  Profile  Ml. 3  depends  on  the  T-  or  A-lmplementation 
Profile,  in  conjunction  with  which  M1.3  is  implemented. 

3  The  support  for  IA5  String  is  the  ISO  646,  IRV  GO  character  set  and  the  ISO  646,  IRV  CO  set. 

4  The  minimum  level  of  support  for  Graphic  String  is  the  ISO  646,  IRV  GO  character  set  and  the  8859-1  GO 
and  G1  sets. 

5  The  minimum  level  of  support  for  General  String  is  the  ISO  646,  IRV  GO  character  set  and  the  8859-1  GO 
and  G1  sets,  and  ISO  646,  IRV  CO  set. 

6  If  the  Character-Set  parameter  is  absent,  the  following  defaults  apply: 
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1  Inivpr^al-rl^i^^-nNrnhpr 

Vi/ 1  II  V  wl  OOI  Vi/ldOO  1  ILJI  i  ik^wl 

CO     GO  G1 

lASString  [22] 
GraphicString  [25] 
VisibleString  [26] 
GeneralString  [27] 

1  2 
2 
2 

1  2 

Character-Sets  and  Escape  Sequences: 


1 

Registration 

Content 

Escape 

number 

Sequence 

1 

CO  set  of  ISO  646 

ESC  2/1  4/0 

2 

ISO  646,  IRV 

6 

ISO  646,  USA  Version-X  3.4  -  1968  (Left-hand  part 

ESC  2/8  4/2 

of  ISO  8859-1) 

100 

Right-hand  part  of  Latin  Alphabet  No  1  ISO  8859-1, 

ESC  2/13  4/1 

ECMA-94 

7.2      FADU  Identities 

In  addition  to  the  Phase  2  FADU  Identity  Agreements  the  following  is  specified: 

-  For  the  document  type  NBS-1 1  used  in  conjunction  with  the  Transfer  service  class  or 
the  Transfer  and  Management  service  class,  the  support  of  the  FADU  identities  of 
'current',  'next',  'previous'  and  'end'  is  outside  the  scope  of  these  Agreements. 


7.3      Access  Control  Attribute 

The  location  field  of  access  control  element  is  optionally  supported.  It  is  the  implementor's  choice  which 
combinations  of  fields  in  an  access  control  element  are  supported.  The  ACE  combination  should  be  stated 
in  the  PICS. 


8     Protocol  Agreements 
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8.1      Implementation  Profile  Ml  .3 

The  functions  defined  for  tlie  Innplementation  Profile  M1.3  shall  always  be  implemented  in  conjunction  with 
one  or  more  of  the  Implementation  Profiles  T1.3,  T2.3,  A1.3,  or  A2.3.  The  service  classes  and  functional 
units  that  shall  be  implemented  are  specified  in  Annex  A,  A.  12.4  and  A.  12.5. 

For  an  implementation  supporting  the  Profile  M1.3  in  conjunction  with  T1.3  or  T2.3,  any  of  the  service 
classes  Transfer,  Management  or  (Transfer,  Management,  Transfer-and -Management)  may  be  requested  and 
any  of  the  classes  Transfer,  Management,  Transfer-and-Management  may  be  responded  on  F-INITIALIZE. 

For  an  implementation  supporting  the  Profile  Ml. 3  in  conjunction  with  A1.3  or  A2.3,  any  of  the  service 
classes  Access  or  Management  may  be  requested  and  responded  on  F-INITIALIZE. 


8.2      Functional  Units 

For  FTAM  Phase  3  implementations  Recovery  and  Restart  Data  Transfer  are  optionally  supported. 
FADU  locking  is  optionally  supported  for  Implementation  Profiles  A1.3  and  A2.3. 


8.3      implementation  Information  Parameter 

In  addition  to  the  Agreements  as  specified  for  FTAM  Phase  2,  part  9  clause  12  ,  the  following  value  is 
defined 

-  NBS-Phase3. 


8.4  F-Check 

In  order  to  maximize  interoperability,  implementations  of  FTAM  service  providers  should  not  restrict  the 
amount  of  data  transmitted  between  successive  F-CHECK  requests  to  a  single  quantity.  Variations  in  the 
amount  of  data  transmitted  between  checkpoints  may  be  required  to  accommodate  differences  in  real  end 
systems  supporting  FTAM  Virtual  Filestores  and/or  in  the  communications  media  underlying  FTAM 
associations.  It  is  required  that  all  FTAM  implementations  are  able  to  receive  at  least  one  PSDU  between 
checkpoints. 


8.5      Error  Recovery 

Procedures  for  Class  I,  II  and  III  errors  are  defined  and  supported  for  FTAM  Phase  3  implementations.  It 
is  the  implementor's  choice  whether  to  handle  class  I  errors  using  F-RESTART  PDUs  or  whether  to  use  the 
class  II  error  procedure. 
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8.5.1       Docket  Handling 

When  a  class  III  error  occurs,  the  length  of  time  a  docket  is  maintained  is  determined  by  the  local  system. 
Recovery  from  a  class  III  error  is  only  possible  as  long  as  both  end  systems  maintain  the  docket. 

It  is  also  a  local  decision  how  many  dockets  can  be  maintained  simultaneously. 


8.5.2       Parameters  for  Error  Recovery 

The  following  information  is  given: 

The  semantics  of  the  <FTAM  quality  of  service>  parameter  is  as  defined  in  ISO  8571 ;  including  the 
local  knowledge  of  FERPM; 

No  minimum  requirement  for  the  <  checkpoint  window >  parameter  or  the  checkpoint  size  is 
defined; 

For  the  < recovery  mode>  parameter  of  F-OPEN,  the  values  'none'  and  'at-start-of-transfer'  are 
supported.  The  value  'at-any-active-checkpoint'  is  optionally  supported.  If  recovery  mode  'at-start- 
of-transfer'  is  negotiated,  no  F-CHECK  shall  be  issued.  When  recovering  at  the  start  of  the  transfer, 
the  < recovery  point>  value  of  0  shall  be  used; 

It  is  required  that  Responders  implementing  the  Restart-data-transfer  or  the  Recovery  functional  unit 
must  be  able  to  negotiate  < recovery  mode>  parameter  to  a  value  other  than  'none'; 

For  the  <diagnostic>  parameter  of  F-INITIALIZE,  F-P-ABORT  and  F-RECOVER  PDUs,  the  term 
<  suggested  delay >  shall  be  supported  if  the  Recovery  functional  unit  is  implemented.  The  Basic 
FERPM  should  wait  at  least  the  amount  of  time  as  given  by  the  <  suggested  delay >  term  before 
attempting  to  recover. 


If  < concurrency  contrd[>  param&ters  are  supportedJTho  <conourronoy  control  >  paramotcro  of  F  SELECT, 
F  CREATE  and  F  OPEN  with  or  without  the  <aooooo  control  >  attribute  of  Soourity  Group  arc  oupportod  for 
Initlatoro  and  optionally  oupportcd  for  Roopondors. 

tf  supported  by  a  Rospondor,  details  of  their  possible  usage  is  a  local  matter  and  shall  be  specified  in  the 


8.6 


Concurrency  Control 


8.6.1 


Concurrency  Control  to  whole  file 


PICS. 


Default  values  for  concurrency  control  are  as  specified  for  FTAM  Phase  2  Agreements. 
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No  minimum  requirement  is  defined  for  <  concurrency  control  >  parameter  values. 

For  a  first  accessor  either  the  specified  concurrency  locks  or  the  default  values  are  assigned.  For  a 
subsequent  accessor  the  access  to  a  file  is  granted  only  if  this  concurrency  control  requirement,  as  specified 
in  this  concurrency  control  parameter  or  given  by  the  default  values,  can  be  met.  Otherwise  the  subsequent 
request  shall  be  rejected. 


8.6.2        FADU  Locking 

FADU  locking  functional  unit  and  the  respective  <FADU  lock>  parameters  are  optionally  supported  for  the 
Implementation  Profiles  A1.3  and  A2.3. 

It  is  understood  that  ISO  8571-4  Clause  18.4  also  applies  to  FADU  locks;  that  means  that  as  long  as  a 
docket  is  maintained,  FADU  locks  locking  any  FADUs  recorded  in  that  docket  should  be  maintained. 


8.7      Create  Password 

The  <  create  password  >  parameter  for  an  implementation  acting  as  an  Initiator  is  supported.  This  parameter 
is  optionally  supported  for  an  implementation  acting  as  a  Responder. 


8.8      Initiator  Identity,  Passwords  and  Account 

An  Initiator  must  be  capable  of  sending  and  not  sending  the  parameters  < initiator  identity >,  <filestore 
password  >,  <  access  passwords  >  and  <  create  password  >  to  satisfy  the  requirements  of  the  Responder. 

The  contents  of  the  <  initiator  identity  >,  <  filestore  password  >,  <  access  passwords  >,  <  create  password  > 
and  <  account  >  parameters  shall  be  in  the  convention  of  the  responding  implementation. 


9     Range  of  Values  for  Integer-Type  Parameter 

In  addition  to  the  parameters  specified  for  FTAM  Phase  2  under  the  same  heading,  the  parameters 


F-RECOVER  request 

bulk-transfer-number 
NBS-AS3 
NBS-Node-Name 

starting-fad  u 

fadu-count 

may  be  encoded  so  that  the  length  of  its  contents  octets  is  no  more  than  eight  octets. 
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ANNEX  A: 
ANNEX  B: 
ANNEX  C: 
ANNEX  D: 
ANNES  E: 


ANNEXES 

PROFILE  REQUIREMENTS  LIST  FOR  NIST  OIW  FTAM  PHASE  3 
NIST  OIW  REGISTER  OF  FTAM  OBJECTS 
CONSTRAINT  SETS 
CONSTRAINT  SETS 
ABSTRACT  SYNTAXES 
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Annex  A  (normative) 
Profile  Requirements  List 


Editor's  Note  -  The  page  numbering  of  the  PICs  tables  may  not  be  aligned  with  the  text  of  this 
document.  The  reason  for  this  problem  is  that  the  PICs  tables  are  coded  using  a  different  wordprocessor. 
The  tables  are  being  converted,  but  until  this  is  completed  the  page  numbering,  and  format  of  the  tables 
may  be  aligned  with  the  test  of  this  document. 


In  the  event  of  a  discrepancy  becomming  apparent  in  the  body  of  these  agreements  and  the  tables  in 
this  annex,  this  annex  is  to  take  precedence. 

Editor's  Note  -  Delete  lines  A.13.9.1.2,  A.13.9.1.3,  A.13.9.1.4,  when  the  PICS  tables  are  converted  to 
WordPerfect  Version  5.1  format. 

Editor's  Note  «  Change  taWe  A.5  to  reference  Annex  (a.       ISO/iECiSP  10607-4:1990  When 

Annex  A  is  converted  to  WordPerfect  V5,l. 


Editor's  Note  -  A.12  16 1,  a,12  16.5,  A  12.17,1,  and  A,12.175  replace  the  *o'  vm  W  bihd  Al<3  cohm> 
Adti  a       t0  tafctes  A  12. 16  and  A.  12. 17  Tor  the  profile  A1.3,  the  support  of  at  ^©a$t  ^om  ol  ln$$^^  fepi?8}«, 
Of  extend  ts  required.'  Also  add  a  note  to  tables  A.12.I6  and  A>t2.i7  •  For  profiles  Ti.3      T2>3t  fhe 
support  of  at  feast  one  of  read,  insert,  replace  or  extend  is  required."  When  Annex  A  ts  converted  to 


Editor's  Note  -  A,1 3,6,1,  and  A.  13,6.2  d-tange  parameter  names  to  "Universal  time",  "Generalized  tfme* 

"]A5Strtng",  "Boolean",  "Bit",  Imeger",  When  Annex  A  is  converted  to  WordPerfect  V5,1. 
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Annex  A 

(normative) 

Profile  Requirements  List  for  NIST  OIW  FTAM  Pliase  3 
A.O  Introduction 

This  annex  to  NIST  FTAM  Phase  3  Agreements  defines  a  Profile  Requirements  List  (PRL)  for  the  Implementation 
Profiles 

T1.3    -     Simple  File  Transfer 
T2.3    -     Positional  File  Transfer 
A1.3    -     Simple  File  Access 
Ml. 3  -  Management 


This  annex  specifies  the  constraints  and  characteristics  of  NIST  OIW  FTAM  Phase  3  on  what  shall  or  may  appear  in 
the  supplier  columns  of  an  FTAM  Phase  3  PICS.  This  annex  is  completely  based  on  ISO  8571-5.  It  uses  only  a 
selection  of  the  tables  from  ISO  8571-5  which  are  necessary  for  the  specification  of  the  FTAM  Phase  3  status,  and 
retains  their  numbering,  in  order  to  facilitate  for  a  supplier  to  fill  in  the  respective  PICS  Proforma. 

This  annex  is  a  summary  of  all  definitions  of  FTAM  Phase  3  as  they  appear  in  the  Stable  Implementation  Agree- 
ments for  OSI  Protocols,  Version  4  Edition  1,  December  1990,  parts  9  and  10. 


A.0.1  Conformance  requirement  of  Base  Standards 

The  D-column  of  clauses  A.I  to  A.I 3  specifies  the  conformance  requirement  of  the  base  standards  ISO  8571,  as 
written  in  ISO  8571-5.  The  definitions  apply  as  defined  in  ISO  8571-5  clause  8.1  : 

m  -    mandatory  support 
0     -  optional  support 
f     -  full  support  of  attributes 
p    -  partial  support  of  attributes 
-   not  applicable 

A  single  value  in  the  D-column  applies  to  the  Initiator  role  of  a  system  as  well  as  to  the  Responder  role.  If  two 
values  are  specified  in  the  D-column  separated  by  a  space,  they  apply  to  the  Initiator  (I)  role  and  to  the  Responder 
(R)  role,  respectively. 


A.0.2  Conformance  requirement  of  Profiles 

The  Conformance  requirement  of  the  Implementation  Profiles  is  specified  in  the  'Profiles'  column/columns  in  clauses 
A.I  to  A.I 3.  The  following  convention  is  applied  for  this  purpose  : 

0   a  'PROFILES'  column  is  valid  for  all  Profiles  T1 .3,  T2.3,  A1 .3  and  Ml  .3 

0   if  different  conformance  requirements  apply  to  different  Profiles,  separate  columns  are  included  in  the  tables,  each 
bearing  the  corresponding  Profile  name  as  its  heading,  or  separate  tables  for  these  Profiles  are  used 
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o   a  single  value  in  these  colunnns  applies  to  the  Initiator  as  well  as  to  the  Responder  role  of  an  implementation 

o   if  two  values  are  specified  in  a  column  separated  by  a  space,  they  apply  to  the  Initiator  (I)  role  and  to  the  Re- 
sponder (R)  role,  respectively. 

For  the  conformance  requirements  of  the  NIST  FTAM  Phase  3  Profiles  the  following  abbreviations  are  used. 

mandatory;  m  : 

This  is  a  mandatory  or  optional  feature  in  the  base  standard,  h  shall  be  supported,  i.e.,  its  syntax  and  procedures 
shall  be  implemented  as  specified  in  the  base  standard  or  in  FTAM  Phase  3  by  all  implementations  claiming 
conformance  to  the  Profile. 

However,  it  is  not  a  requirement  that  the  feature  shall  be  used  in  all  instances  of  communication,  unless  mandated 
by  the  base  standard  or  stated  othenA/ise  in  FTAM  Phase  3. 

For  fully  supported  attributes,  this  implies  that  at  least  the  minimum  range  of  attribute  values,  as  defined  in  ISO 
8571-2,  shall  be  supported  unless  stated  otherwise  in  FTAM  Phase  3. 

Also  for  features  which  are  optional  in  the  base  standard,  conformant  implementations  shall  be  able  to  interwork 
with  other  implementations  not  supporting  this  feature. 

The  support  of  a  feature  can  be  conditional,  depending  on  the  support  of  a  class  of  features  to  which  it  belongs, 
e.g.,  an  attribute  in  an  attribute  group,  a  parameter  in  a  PDU,  a  PDU  in  a  functional  unit. 

optional;  o : 

It  is  left  to  the  implementation  as  to  whether  this  feature  is  implemented  or  not. 

If  an  attribute  group  with  a  support  level  of  'o'  is  chosen  to  be  supported,  then  all  the  attributes  in  this  group  that  are 
classified  as 'm'  shall  be  supported. 

The  support  for  PDUs  is  determined  by  the  negotiation  of  functional  units  when  the  connection  is  established. 

If  a  parameter  is  optionally  supported,  then  its  syntax  shall  be  implemented,  but  it  is  left  to  each  implementation 
whether  its  procedures  are  implemented  or  not. 

When  receiving  an  optional  parameter  which  is  not  subject  of  negotiation  and  is  not  supported  by  the  Receiver,  the 
Receiver  shall  at  least  inform  the  Sender  by  informative  diagnostic  and  interworking  shall  not  be  disrupted. 

conditional;  c : 

This  feature  shall  be  supported  under  the  conditions  specified  in  FTAM  Phase  3.  If  these  conditions  are  not  met,  the 
feature  is  outside  the  scope  of  the  Profile. 

excluded;  x : 

This  feature  is  excluded  from  the  Profile.  The  implementor's  answer  in  the  PICS  shall  always  be  'no', 
outside  the  scope;  I : 

This  feature  is  outside  the  scope  of  the  Profile,  i.e.,  it  may  be  ignored,  and  will  therefore  not  be  subject  of  a  Profile 
conformance  test.  However  the  syntax  of  all  parameters  of  supported  PDUs  shall  be  implemented,  even  if  their 
procedures  are  not  (i.e.,  the  Receiver  shall  be  able  to  decode  the  PDU). 

not  applicable;  - : 

This  feature  is  not  defined  in  the  context  where  it  is  mentioned,  e.g.,  a  parameter  which  is  not  part  of  the  respective 
PDU.  The  occurrence  of  'not  applicable'  features  is  mainly  due  to  the  format  of  the  tables  in  the  Phase  3  Profiles 
Requirements  List. 


16 


Part  10  -  FTAM  Phase  3  March  1991  (Stable) 

Section  1 

A.1  (void) 
I  A.2  (void) 

I  Section  2:  General  ISO  8571  Detail 


A.3  ISO  8571  Protocol  versions 


1 

FTAM  protocol  version  number(s)  version-1 

A.4  ISO  8571  Addenda 

1 

ISO  8571-1  — 

2 

ISO  8571-2  — 

3 

ISO  8571-3  — 

4 

ISO  8571-4  — 

5 

ISO  8571-5  — 

A.5  Defect  report  numbers  and  amendments 

1 

ISO  8571-1  — 

2 

ISO  8571-2  — 

3 

ISO  8571-3  — 

4 

ISO  8571-4  — 

5 

ISO  8571-5  — 

i 

A.6  Global  statement  of  conformance 

1 

Does  FTAM  Phase  3  conform  to  ISO  8571  ?  yeS 

17 
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A.7  Initiator  /  Responder  capability 

ROLES 

D 

PROFILES 

1  R 

Sender 

0 

O  0 

Receiver 

0 

o  o 

NOTE  -  See  part  9  18.1 


A.8  Application  Context  Name  details 


ISO  8571-4  defines  a  value  for  a  simple  transfer  mechanism.  Other  values  are  not  defined  for  FTAM  Phase  3 
(see  part  9  5.9). 
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Annex  B  (normative)  

Register  of  FTAM  Objects 

Thft  objects  defined  In  B^*1  and       will  be  removed  from  this  document  after  iSO/lEC  tSP  tOfiOM 
mi  ISO/tEC  i$P  10607-a/Amd«1  are  publistied.  During  the  period  between  publishing  tine  ISP  and  the 
removal  of  tbe  definitions  tram  this  document  the  defimtions  in  tbe  \SP  wil  take  precedence  ovjr^thlf 
docutnertt. 

Wtfi^tbe  obiect  definltiotis  are  removed,  dauses  S,a.t  and  BJLZyM  be  chm^W 
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Object  Descriptor 

Object  Identifier 

D 

T1.3 

T2.3 

A1.3 

M1.3 

1 

FTAM  PCI 

{iso  standard  8571  abstract-syntax(2) 
ftam-pci(l) } 

m 

m 

m 

m 

m 

2 

FTAM  FADU 

{iso  standard  8571  abstract-syntax(2) 
ftam-tadu(2) } 

o 

m 

m 

3 

{joint-iso-ccitt  association-control(2) 
abstract-syntax(l)  apdus(O)  versionl(l) } 

m 

m 

m 

m 

m 

4 

FTAM  unstructured 
text  abstract  syntax 

{iso  standard  8571  abstract-syntax(2) 
unstructured-text(3) } 

0 

m 

m 

m 

- 

5 

FTAM  unstructured 
binary  abstract  syntax 

{iso  standard  8571  abstract-syntax(2) 
unstructured-binary(4)  } 

0 

m 

m 

m 

6 

NBS  file  directory 
entry  abstract  syntax 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-as2(2) } 

c 

c 

c 

7 

NBS  abstract 
syntax  AS1 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-as1(1)  } 

- 

i 

c 

c 

■ 

8 

NBS  random  access 
node  name  abstract 
syntax 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-node-name(3) } 

- 

c  c 

see  clause  9 

- 

9 

NBS  random  binary 
access  file  abstract 
syntax 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-random-binary(4) } 

i 

c 

c 

10 

NBS  simple  text 
abstract  syntax 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-simple-text(5) } 

i 

c 

c 

NOTES 

1  The  abstract  syntaxes  whichi  are  supported  in  tfie  implementation  Profile  W.S  depend  on  the  T-or  A-Profile  in  conjunction  with 
which  M1.3  is  implemented. 

2  The  support  requirements  for  the  conditional  abstract  syntaxes  depend  on  the  constraint  sets  and  document  types  which  are 
implemented  (see  clause  A.  13). 

3  ISO  8571  requires  the  presence  of  the  transfer  syntax  derived  from  the  "Basic  Encoding  of  a  single  ASN.1  type  "{joint-iso-ccitt 
asnl  (1)  basic-encoding  (1)}  encoding  rules  for  transfer  of  the  "FTAM  PCI"  and  the  "FTAM  FADU"  abstract  syntaxes.  Implementa- 
tion detail  of  this  transfer  syntax,  and  other  transfer  syntaxes  supported,  is  specified  in  the  PICS  of  ISO  8823. 
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Section  4  :  Virtual  Filestore  Detail 


A.10  Virtual  filestore 

This  clause  details  the  conformance  to  the  file  model,  file  attribute  support  and  to  file  structure  support. 
A.10.1  File  model 


FILE  MODEL 

D 

PROFILES 
R 

Hierarchical 

0 

m 

Other  models  i 

A.I 0.2  Attributes 

A.1 0.2.1  Attribute  groups 


ATTRIBUTE  GROUP  NAME 

D 

PROFILES 

1 

Kernel 

m 

m 

2 

Storage 

0 

o 

3 

Security 

0 

o 

4 

Private 

0 

i 

A.10.2.2  Attribute  values 

KERNEL  GROUP 
(INITIATOR) 

D 

PROFILES 
1  full 

RANGE  OF  VALUES 

1 

Filename 

f 

m 

see  A.10.2.3 

2 

Permitted  Actions 

f 

m 

3 

Contents  Type 

f 

m 

see  A.  12.7 

KERMEL  GROUP 
(RESPONDER) 

D 

PROFILES 

R  full 

RANGE  OF  VALUES 

4 

Filename 

f 

m 

see  A.10.2.3 

5 

Permitted  Actions 

f 

m 

6 

Contents  Type 

f 

m 

see  A.I 2.7 
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STORAGE  GROUP 
(INITIATOR) 

D 

PROFILES 
1  full 

RANGE  OF  VALUES 

7 

Storage  account 

f 

m 

8 

File  availability 

f 

m 

9 

Future  filesize 

f 

m 

see  part  9  1 7  9 

NOTE  -  An  initiator  shall  not  partially  support  attributes 

STORAGE  GROUP 
(RESPONDER) 

D 

PROFILES 
R  full               R  partial 

RANGE  OF  VALUES 

10 

Storage  account 

P 

o 

o 

11 

Date  and  time  of  creation 

P 

o 

o 

12 

Date  and  time  of  last  modification 

P 

o 

o 

13 

Date  and  time  of  last  read  access 

P 

o 

o 

14 

Date  and  time  of  last  attribute  modification 

P 

o 

o 

15 

Identity  of  creator 

P 

o 

o 

16 

Identity  of  last  modifier 

P 

o 

o 

Identity  of  last  reader 

P 

o 

o 

|ia 

Identity  of  last  attribute  modifier 

P 

o 

o 

|i. 

File  availability 

P 

m 

X 

Filesize 

P 

m 

X 

see  part  9  17.9 

(21 

Future  filesize 

P 

o 

o 

see  part  9  17.9 

1 

3 

SECURITY  GROUP 
(INITIATOR) 

D 

PROFILES 
1  full 

RANGE  OF  VALUES 

Access  control 

f 

m 

see  A.12.2 

la 

Legal  qualifications 

f 

m 

|i 

NOTE  -  An  initiator  sfiall  not  partially  support  attributes 

SECURITY  GROUP 
(RESPONDER) 

D 

PROFILES 
R  full             R  partial 

RANGE  OF  VALUES 

Access  control 

P 

m 

X 

see  A.12.2,  part  9  9.2 

Legal  qualifications 

P 

o 

o 
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A.I 0.3  File  structures 
A«10.3.1  Constraint  sets 


See  part  9  9.1 


CONSTRAINT  SET  NAME 

D 

T1.3 

T2.3 

A1.3 

M1.3 

Unstructured 

0 

m 

m 

fn 

Sequential  Flat 

0 

i 

m 

m 

Ordered  flat 

0 

i 

@ 

o 

Ordered  flat  widi  unique  names 

0 

1 

o 

© 

Ordered  hierarchical 

0 

i 

! 

8 

General  hierarchical 

0 

i 

i 

i 

General  hierarchical  with  unique  names 

0 

i 

i 

i 

NBS  ordered  flat                                    -                       1                        @                       ©  - 

NBS  random  access 

i 

o 

o 

A.1 0.3.2  File  and  filestore  actions 

A.1 0.3.2.1  Filestore  Actions 

Support  for  filestore  actions  is  dependent  upon  the  functional  units  implemented  (see  A.I 2.4  and  A.I  2.5) 

A.10.3.2,2  File  Actions 


CONSTRAINT  SET 

RESPONDER 

unstructured 

ACTION 

D  T1.3 

Locate   

Read 

0  0 

Insert   

Replace 

0  o 

Extend 

0  0 

Erase 

0  i 
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CONSTRAINT  SET 

RESPONDER 

unstructured 

sequential 
flat 

ordered 
flat 

ordered  flat 
with  unique 
names 

NBS 
ordered 
flat 

NBS 
random 
access 

ACTION 

D  T2.3 

D  T2.3 

D 

T2.3 

D 

T2.3 

D  T2.3 

D  T2.3 

7 

Locate 

0  i 

0 

0 

i 

i 

e 

Read 

0  o 

0  o 

0 

o 

0 

o 

o 

o 

9 

Insert 

0  o 

0 

o 

0 

o 

o 

o 

10 

Replace 

0  o 

0 

o 

0 

o 

o 

o 

11 

Extend 

0  o 

0 

o 

0 

o 

12 

Erase 

0  1 

0  1 

0 

i 

0 

i 

i 

CONSTRAINT  SET 

RESPONDER 

unstructured 

sequential 
fiat 

ordered 
flat 

ordered  flat 
witfi  unique 
names 

NBS 
ordered 
flat 

NBS 
random 
access 

ACTION 

D  A1.3 

D  A1.3 

D 

A1.3 

D 

A1.3 

D  A1.3 

D  A1.3 

13 

Locate 

0  o 

0 

o 

0 

o 

o 

o 

14 

Read 

0  o 

0  o 

0 

o 

0 

o 

o 

o 

15 

Insert 

0  o 

0 

o 

0 

o 

o 

o 

16 

Replace 

0  o 

0 

o 

0 

o 

o 

o 

17 

Extend 

0  o 

0 

o 

0 

o 

18 

Erase 

0  o 

0  o 

0 

o 

0 

o 

o 

o 

NOTE  -  File  actions  are  not  defined  in  Implementation  Profile  M1.3 
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CONSTRAINT  SET 

RESPONDER  unstructured 

ACCESS  CONTEXT  D  T1.3 

US   

UA  o  m 

FS   

FL   

FA   

HN   

HA   


CONSTRAINT  SET 

RESPONDER 

unstructured  sequential 

ordered 

ordered  flat 

NBS 

NBS 

with  unique 

ordered 

random 

flat 

flat 

names 

flat 

access 

ACCESS  CONTEXT 

D     T2.3         D  T2.3 

D  T2.3 

D  T2.3 

D  T2.3 

D  T2.3 

US 

UA 

0       m          0  m 

0  m 

0  m 

m 

m 

FS 

FL 

FA 

  0  m 

0  m 

0  m 

m 

HN 

HA 

o  o 

0  o 

o 
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CONSTRAINT  SET 

RESPONDER 

unstructured  sequential 
flat 

ordered 
fiat 

ordered  flat 
with  unique 
names 

NBS 
ordered 
flat 

NBS 
random 
access 

ACCESS  CONTEXT 

D     A1.3         D  A1.3 

D  A1.3 

D  A1.3 

D  A1.3 

D  A1.3 

US 

UA 

0       m          0  m 

0  m 

0  m 

m 

m 

FS 

FL 

FA 

0  m 

0  m 

m 

  0  m 

HN 

HA 

0  o 

0  o 

o 

NOTE  -  The  supported  access  contexts  for  Impementation  Profile  M1.3  are  defined  in  the  T-  or  A-Profile  in  conjunction  with  which 
M1.3  is  implemented. 


A.10.4  Additional  information 

( Void ) 


A.10.5  Override 


RESPONDER  OVERRIDE 

D 

PROFILES 
R 

1 

Create  failure 

0 

m 

2 

Select  old  file 

0 

m 

3 

Delete  and  recreate  with  old  attributes 

0 

o 

4 

Delete  and  create  with  new  attributes 

0 

m 

NOTE  -  The  specification  of  the  role  of  initator  is  given  in  A.  12. 15. 
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Section  5  :  File  Protocol  Detail 

A.11  File  protocol 

See  part  9  clauses  5.1  •  5.3  and  17 

Subclauses  A.11. 2  to  A.1 1.24  specify  an  indication  of  which  PDUs  are  supported.  The  conformance  requirements 
for  PDUs  are  dependent  on  the  particular  functional  units  implemented.  PDUs  indicated  in  A.1 1.8  to  A. 11. 24  as 
conditional  shall  be  considered  as  mandatory  when  a  particular  functional  unit  is  implemented,  according  to  the 
following  table. 


PDUs 

Clause 

Functional  Units 

Ker- 
nel 

Read 

Write 

Ac- 
cess 

LFM 

EFM 

Grou- 
ping 

Reco- 
very 

Re- 
start 

F-CREATE 

A.11. 8 

m 

F-DELETE 

A.11. 9 

m 

F-READ-ATTRIB 

A.11. 10 

m 

F-CHANGE-ATTRIB 

A.11. 11 

m 

F-OPEN 

A.11. 12 

m 

m 

F-CLOSE 

A.11. 13 

m 

m 

F-BEGIN-GROUP 

A.11. 14 

m 

F-END-GROUP 

A.11. 15 

m 

F-RECOVER 

A.11. 16 

m 

F-LOCATE 

A.11. 17 

m 

F-ERASE 

A.11. 18 

m 

F-READ 

A.11. 19 

m 

F-WRITE 

A.1 1.20 

m 

F-DATA-END 

A.1 1.21 

m 

m 

F-TRANSFER-END 

A.1 1.22 

m 

m 

F-CANCEL 

A.1 1.23 

m 

m 

F-RESTART 

A.1 1.24 

m 

NOTES 

1  In  order  to  keep  the  protocol  tables  compact  some  forward  references  have  been  introduced  to  clauses  which  expand  upon  the 
detail  of  field  support. 

2  The  FTAM  protocol  will  require  a  number  of  optional  lower  layer  services  to  be  available  (e.g.,  Application  Entity  Titles  in  ACSE). 
This  requirement  is  outside  the  scope  of  this  Profiles  Requirements  List. 
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A.11.1  GraphicString  support 
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( Void  ) 

A.11.2  FTAM  regime  establishment 


1 

U 

R 

rHUrlLco 
i  R 

1 

F-INITIALIZE  PDU 

m 

m 

m  m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

State  result 

- 

m 

m 

all  values  defined  in  ISO  8571 

3 

Action  result 

- 

m 

m 

all  values  defined  in  ISO  8571 

4 

Protocol  version 

m 

m 

m  m 

see  Section  2 

5 

Implementation  information 

0 

0 

o  o 

see  A.  12.1 

6 

Presentation  context  management 

m 

m 

m  m 

see  note  1,  part  9  17.10 

7 

Service  class 

m 

m 

m  m 

see  A.  12.4 

8 

Functional  units 

m 

m 

m  m 

see  A. 12.5 

9 

Attribute  groups 

m 

m 

m  m 

see  A.  10.2 

10 

Shared  ASE  information 

0 

o 

i  1 

see  part  9  5.8 

11 

FTAM  Quality  of  Service 

m 

m 

m  m 

see  A. 12.8 

12 

Contents  type  list 

0 

0 

m  m 

see  A.I  2.7.1,  part  9  18.4 

13 

Initiator  identity 

0 

m 

see  8.8,  part  9  16.1  and  18.4 

14 

Account 

0 

o 

see  8.8,  part  9  18.4 

15 

Filestore  password 

0 

m 

see  A,12.11,  8.8,  part  9  15.1 

15 

Diagnostic 

0 

m 

see  A.12.6,  8.5.2,  part  9  13 

17 

Checkpoint  window 

m 

m 

m  m 

see  note  2,  8.5.2 

NOTES 

1  The  values  available  for  the  presentation  context  management  field  depend  upon  the  functional  units  implemented  in  ISO  8823. 

2  Checkpoint  window  field  is  indicated  as  mandatory  in  accordance  with  ISO  8571-4.  The  field  is  defaulted  to  the  value  1. 
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A.1 1.3  FTAM  regime  termination  (orderly) 

December  1990  (Stable) 

D 
S  R 

PROFSLES 
1  R 

F-TERMINATE  PDU                     m  m 

m  m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Shared  ASE  information                o  o 

i  i 

see  part  9  5.8 

Charging                                 -  o 

-  o 

see  A.12.10 

A.11.4  FTAM  regime  termination  (abrupt)  by  service  user 

D 

PROFSLES 

F-U-ABORT  PDU  m 

m 

FIELD  HAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result  m 

m 

all  values  defined  in  ISO  8571 

Diagnostic  o 

m 

see  A.  12.6,  part  9  13 

A.11.5  FTAM  regime  termination  (abrupt)  by  service  provider 

D 

PROFILES 

F-P-ABORT  PDU                        m  m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result  m 

m 

all  values  defined  in  ISO  8571 

Diagnostic  o 

m 

see  A.12.6,  8.5.2,  part  9  13 
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D 
1  R 

PROFILES 
1  R 

F-SELECT  PDU 

m  m 

in  m 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

State  result 

m 

m 

all  values  defined  in  ISO  8571 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

Attributes 

m  m 

m  m 

see  A.  10.2,  part  9  17.9 

Requested  access 

m 

m 

see  A.12.16 

Access  passwords 

0 

m 

see  8.8,  part  9  16.2 

Concurrency  control 

o 

o 

see  A.12.13,  8.6.1 

Shared  ASE  information 

0  0 

1  1 

see  part  9  5.8 

Account 

0 

o 

see  8.8,  part  9  18.4 

Diagnostic 

0 

m 

see  A.I  2.6,  part  9  13 

A.1 1.7  File  deselection 

D 
1  R 

PROFILES 
1  R 

F-DESELECT  PDU 

m  m 

m  m 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

Action  result 

m 

-  m 

all  values  defined  in  ISO  8571 

Charging 

o 

o 

see  A.  12. 10 

Shared  ASE  information 

0  0 

1  i 

see  part  9  5.8 

Diagnostic 

0 

-  m 

see  A.  12.6,  part  9  13 
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A.11.8  File  creation 


D 
I  R 

PROFILES 
1  R 

1 

F-CREATE  PDU 

c  c 

c  c 

see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

State  result 

m 

m 

all  values  defined  in  ISO  8571 

3 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

4 

Override 

m 

m 

see  A.I 2.1 5 

5 

Initial  attributes 

m  m 

m  m 

see  A.10.2,  part  9  10.2.2,17.9 

5 

Create  password 

0 

m  - 

see  A.12.12,  8.7,  8.8, 
part  9  16.2 

7 

Requested  access 

m 

m 

see  A.12.16 

8 

Access  passwords 

0 

m 

see  8.8,  part  9  16.2 

9 

Concurrency  control 

0 

o  - 

see  A.12.13,  8.6.1 

10 

Shared  ASE  information 

0  0 

see  part  9  5.8 

11 

Account 

0 

o  - 

see  8.8,  part  9  18.4 

12 

Diagnostic 

0 

m 

see  A.  12.6,  part  9  13 

A.1 1.9  File  deletion 


D 
1  R 

PROFILES 
1  R 

1 

F-DELETE  PDU 

c  c 

c  c 

see  A.11,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

3 

Shared  ASE  information 

0  0 

i  i 

4 

Charging 

-  0 

-  o 

see  A. 12.10 

5 

Diagnostic 

0 

rn 

see  A.I 2.6,  part  9  13 
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0 
1  R 

PRORLES 
1  R 

1 

F-READ-ATTRIB  PDU 

c  c 

c  c 

see  A.11.  A.  12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

Action  result 

-  m 

-  m 

all  values  defined  in  ISO  8571 

3 

Attribute  names 

m 

m  - 

4 

Attributes 

-  0 

-  m 

see  A.  10.2,  part  9  17.9 

5 

Diagnostic 

-  0 

-  m 

see  A.12.6,  part  9  13 

A.1 1 .1 1  Change  attributes 

D 
1  R 

T1.3,  T2.3,  A1.3 

Ml. 3 
1  R 

1 

F-CHANGE-ATTRIB 

c  c 

i 

m  m 

see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

Action  result 

m 

i 

-  m 

all  values  defined  in  ISO  8571 

1 

Attributes 

m  0 

i 

m  m 

see  A.10.2,  part  9  17.9 

4 

Diagnostic 

0 

1 

-  m 

see  A.12.6,  part  9  13 

A.11.12  File  open 

D 
1  R 

T1.3,  T2.3,  A1.3 
1  R 

M1.3 

1 

F-OPEN  PDU 

c  c 

tn  m 

i 

see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

State  result 

m 

•  m 

1 

ail  values  defined  in  ISO  8571 

1 

Action  result 

m 

m 

i 

all  values  defined  in  ISO  8571 

i* 

Processing  mode 

m 

m 

i 

see  A.  12.1 7 

1.5 

Contents  type 

m  m 

m  m 

1 

see  A.12.7.2 
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6 

Concurrency  control 

0 

0 

o 

o 

see  A.  12. 13,  8.6.1 

7 

Shared  ASE  information 

0 

0 

i 

i 

see  part  9  5.8 

a 

Enable  FADU  locking 

m 

m 

— — ■ 



false  for  T1.3  and  T2.3 

9 

Activity  identifier 



0 

o 

10 

Diagnostic 

0 

m 

see  A.I 2.6,  part  9  13 

11 

Recovery  mode 

m 

m 

m 

m 

see  A.  12.18 

12 

Remove  contexts 

0 

1 
1 

13 

Define  contexts 

0 

i 

i 

14 

Presentation  action 

m 

m 

i 

see  note 

NOTE  -  The  values  depend  upon  the  functional  units  implemented  in  ISO  8823. 

A.11.13  File  close 


D 

T1.3,  T2.3,  A1.3 

M1.3 

F-CLOSE  PDU  c 

m 

i 

see  A.11.  A.12.5 

FIELDNAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result  m 

m 

i 

all  values  defined  in  ISO  8571 

Shared  ASE  information  o 

i 

i 

see  part  9  5.8 

Diagnostic  o 

m 

1 

see  A.I 2.6,  part  9  13 

A.11.14  Beginning  of  grouping 

D 

  1  R 

T1.3,  T2.3 
1  R 

A1.3 
1  R 

F-BEGIN-GROUP  PDU                 c  c 

m  m 

o  o 

see  A.11,  A.12.5 

FIELDNAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Threshold                                 m  - 

m 

m 

A.11.15  End  of  grouping 

D 

T1.3,  T2.3 

A1.3 

F-END-GROUP  PDU  c 

m 

o 

see  A.11,  A.12.5 

The  F-END-GROUP  PDU  carries  no  fields. 
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December  1990  (Stable) 


See  8.5 


D 
1  R 

T1.3,  T2.3,  A1.3 
1  R 

Ml. 3 

1 

F-RECOVER  PDU 

c  c 

c  c 

1 

see  A.1 1,  A.  12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

State  result 

-  m 

-  m 

1 

all  values  defined  in  ISO  8571 

3 

Action  result 

-  m 

-  m 

i 

all  values  defined  in  ISO  8571 

4 

Activity  identifier 

m  - 

m  - 

i 

5 

Bulk  transfer  number 

m 

m 

1 

see  clause  9 

6 

Requested  access 

m 

m 

i 

see  A.12.16 

7 

Access  passwords 

0  - 

m 

1 

see  8.8,  part  9  16.2 

8 

Contents  type 

m 

-  m 

1 

see  A.  12.7.2 

9 

Recovery  point 

m  m 

m  m 

i 

10 

Diagnostic 

-  0 

m 

1 

see  A.12.6,  8.5.2,  part  9  13 

11 

Remove  contexts 

0  - 

i  - 

1 

see  notes 

12 

Define  contexts 

0  - 

i  - 

i 

see  notes 

13 

Presentation  action 

m 

m 

see  notes 

NOTES 

1  The  values  available  for  the  presentation  action  field  depend  upon  the  functional  units  implemented  in  ISO  8823. 

2  Presentation  action  field  is  indicated  as  mandatory  in  accordance  with  ISO  8571-4.  The  field  is  defaulted  to  no  action. 

A.11.17  Locate  file  access  data  unit 

D 
1  R 

T1.3,  T2.3  A1.3 
1  R 

M1.3 

1 

F-LOCATE  PDU 

c  c 

i                   m  m 

see  A.11,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result 

-  m 

1                  -  m 

1 

all  values  defined  in  ISO  8571 

3 

FADU  identity 

m  0 

i                  m  o 

see  part  9  17.9 

4 

FADU  lock 

0  - 

i                  o  - 

see  A.12.14 

5 

Diagnostic 

0 

i                  •  m 

i 

see  A.12.6,  part  9  13 
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A.11.18  Erase  file  access  data  unit 
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D       T1.3,  T2.3 
i  R 

A1.3 
i  R 

Ml. 3 

F-ERASE  PDU 

c      c  1 

m  m 

1 

see  A.11,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

m  i 

-  m 

all  values  defined  in  ISO  8571 

FADU  identity 

m    -  i 

m 

see  part  9  17.9 

Diagnostic 

-    0  i 

-  m 

see  A.I 2.6,  part  9  13 

A.11. 19  Read  bulk  data 


D 

1  R 

T1.3,  T2.3 
1  R 

A1 

1 

.3 
R 

Ml. 3 

F-READ  PDU 

c  c 

c  c 

m 

m 

see  A.11,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

FADU  identity 

m 

m 

m 

see  part  9  17.9 

Access  context 

m  - 

m  - 

m 

see  A. 10.3. 2.3 

FADU  lock 

0 

o 

1 

A.11. 20  Write  bulk  data 


D 

!  R 

T1.3,  T2.3 
1  R 

A1.3 
1  R 

Ml. 3 

F-WRITE  PDU 

c  c 

c  c 

m  m 

i 

see  A.11,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

FADU  operation 

m  - 

m 

m 

FADU  identity 

m  - 

m 

m  - 

see  part  9  17.9 

FADU  Lock 

0  - 

1 

o 

i 
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A.1 1 .21  End  of  data  transfer 


December  1990  (Stable) 


D 

T1.3,  T2.3,  A1.3 

Ml. 3 

F-DATA-END  PDU 

c 

m 

i 

see  A.1 1,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

m 

m 

i 

all  values  defined  in  ISO  8571 

Diagnostic 

0 

m 

see  A.1 2.6,  part  9  13 

A.11.22  End  of  transfer 

D 
1  R 

T1.3,  T2.3,  A1.3 
1  R 

Ml. 3 

F-TRANSFER-END  PDU 

c  c 

m  m 

i 

see  A.11,  A.12,5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

m 

-  m 

i 

all  values  defined  in  ISO  8571 

Shared  ASE  information 

0  0 

i  i 

see  part  9  5.8 

Diagnostic 

-  0 

-  m 

see  A.  12.6,  part  9  13 

A.11.23  Cancel  data  transfer 

See  part  9  clause  1 1 

D 

T1.3,  T2.3,  A1.3 

Ml. 3 

F-CANCEL  PDU 

c 

m 

see  A.11,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

m 

m 

i 

all  values  defined  in  ISO  8571 

Shared  ASE  information 

0 

1 

see  part  9  5.8 

Diagnostic 

0 

m 

i 

see  A.  12.6,  part  9  13 

A.1 1 .23.1  F-CANCEL  mapping 


See  part  9  clauses  11  and  17.10 
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A.11.24  Restart  data  transfer 

December  1990  (Stable) 

D            T1.3,  T2.3,  A1.3 

M1.3 

F-RESTART  PDU                        c  c 

see  A.11,  A,12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Checkpoint  identifier                    m                     m  i 

A.12  Expanded  PDU  field  and  filestore  detail 

This  clause  identifies  further  PDU  field  and  filestore  detail  to  expand  on  that  given  in  A. 

10  and  A.11. 

A.12.1  Smplementation  information  detail 

See  8.3,  part  9  5.6  and  12 

A.12.2  Access  control  detail 

See  7.3,  part  9 

9.2 

Access  control  element  terms 

D 

PROFILES 

RANGE  OF  VALUES 

Action  list  m 

m 

Concurrency  access  o 

o 

see  A.  12.3,3 

identity  o 

o 

Passwords  o 

o 

see  A.I 2.3.5,  A.I 2.3.6,  8.8 

Location  o 

o 

A.12.3  Access  control  element  detail 

A.I  2.3.1  Action  list  detail  (initiator) 

( Void  ) 

A.I  2.3.2  Action  list  detail  (responder) 

«  ( Void  ) 
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A.1 2.3.3  Concurrency  access  term 

If  the  concurrency  access  term  is  supported  in  \he  access  control  element  the  following  details  of  the  concurrency 
control  shall  be  available  with  each  action. 


T1.3 
Action 

not  required 
D  T1.3 

shared 
D 

T1.3 

exclusive 
D  T1.3 

no  access 
D  T1.3 

1 

Read 

0 

o 

0 

o 

0 

o 

0  o 

2 

Insert 

0 

i 

0 

i 

0 

1 

0  1 

3 

Replace 

0 

o 

0 

o 

0 

o 

0  o 

4 

Extend 

Q 

Q 

o 

o 

0 

o 

0  o 

5 

Erase 

0 

i 

0 

0 

0  i 

6 

Read  attributes 

0 

o 

0 

o 

0 

o 

0  o 

7 

Change  attributes 

0 

1 

0 

1 

0 

1 

0  i 

8 

Delete  file 

0 

o 

o 

o 

0 

o 

0  o 

T2.3 
Action 

not  required 
D  T2.3 

shared 
D 

T2.3 

exclusive 
D  T2.3 

no  access 
D  T2.3 

9 

Read 

0 

o 

0 

o 

0 

o 

0  o 

10 

Insert 

0 

o 

0 

o 

0 

o 

0  0 

11 

Replace 

0 

o 

0 

o 

0 

o 

0  0 

12 

Extend 

0 

o 

0 

o 

0 

o 

0  o 

13 

Erase 

0 

0 

1 

0 

i 

0  i 

14 

Read  attributes 

0 

o 

0 

o 

0 

o 

0  o 

15 

Change  attributes 

0 

i 

0 

1 

0 

1 

0  i 

16 

Delete  file 

0 

o 

0 

o 

0 

o 

0  o 

I 


I 
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A1.3 
Action 

not  required 
D  A1.3 

sliared 
D 

A1.3 

exclusive 
D  A1.3 

no  access 
D  A1.3 

17 

Read 

0 

o 

0 

o 

0 

o 

0  o 

18 

Insert 

0 

o 

o 

o 

0 

o 

0  o 

19 

Replace 

0 

o 

0 

o 

0 

o 

0  o 

20 

Extend 

0 

o 

0 

o 

0 

o 

o  o 

21 

Erase 

0 

o 

0 

o 

0 

o 

0  o 

22 

Read  attributes 

0 

o 

o 

o 

0 

o 

0  o 

23 

Change  attributes 

0 

i 

0 

1 

o 

i 

0  i 

24 

Delete  file 

o 

o 

0 

o 

0 

o 

0  o 

Ml .3             not  required 
Action  D 

M1.3 

shared 

D 

Ml. 3 

exclusive 
D 

no  access 

Ml. 3      D  M1.3 

25 

Read 

0 

i 

0 

0 

i 

0  1 

26 

Insert 

0 

i 

0 

0 

1 

0  1 

27 

Replace 

0 

i 

0 

0 

0  i 

28 

Extend 

0 

1 

0 

0 

0  1 

29 

Erase 

0 

1 

0 

i 

0 

0  i 

30 

Read  attributes 

0 

o 

0 

o 

0 

o 

0  o 

31 

Change  attributes 

0 

o 

0 

o 

0 

o 

0  o 

32 

Delete  tile 

0 

o 

0 

o 

0 

o 

0  o 

A.1 2.3.4  Identity  term 

( Void  ) 


A.1 2.3.5  Initiator  access  passwords 


if  the  passwords  term  of  the  access  control  element  is  implemented  the  following  values  shall  be  supported  for  the 
initiator  role. 

 See  part  9  16.3  


Initiator  Access  Passwords 

D 

PROFILES 

1 

OctetString 

0 

o 

2 

GraphicString 

0 

o 
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A.I  2.3.6  Responder  access  passwords 

If  the  passwords  term  of  the  access  control  element  is  implemented  the  following  values  shall  be  supported  for  the 
responder  role. 


See  part  9  16.3 


Responder  Access 
Passwords 

D 

T1.3 
OctetString 
GraphicString 

T2.3 
OctetString 
GraphicString 

A1.3 
OctetString 
GraphicString 

M1.3 
OctetString 
GraphicString 

Read-password 

0 

o 

o 

o 

i 

Insert-password 

0 

i 

o 

o 

i 

Replace-password 

0 

o 

o 

o 

1 

Extend-password 

o 

o 

o 

o 

Erase-password 

0 

o 

Read-attribute-password 

o 

o 

o 

o 

o 

Change-attribute-password 

0 

i 

i 

o 

Delete-password 

0 

o 

o 

o 

o 

A.I  2.3.7  Location  term 

( Void  ) 

A.1 2.3.7.1  Application  Entity  Titles  detail 

See  part  9  5.7 


A.I  2.3.8  Access  control  element  combinations 


Combinations 

D 

PROFILES 
R 

Identity 

Password 

Location 

0 

o 

Identity 

Password 

0 

o 

Identity 

Location 

0 

o 

Password 

Location 

0 

o 

Identity 

0 

o 

Password 

0 

o 

Location 

0 

o 

NOTE  -  Implementation  of  access  control  without  any  of  the  above  combinations  is  valid. 
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A.12.4  Service  class  field  detail 


December  1990  (Stable) 


See  5.1,  8.1,  part  9  table  7 


D 

T1.3,  T2.3 

A1.3 

Ml  .3  (T) 

Ml. 3  (A) 

1 

Transfer  class 

o 

m 

1 

m 

i 

2 

Access  class 

0 

i 

m 

i 

m 

3 

Management  class 

0 

1 

1 

m 

m 

4 

Transfer  and  management  class 

0 

o 

i 

m 

i 

5 

Unconstrained  class 

0 

i 

i 

1 

NOTES 

1  The  initiator  is  only  permitted  to  specify  those  combinations  defined  in  ISO  8571-3 

2  The  notation  M1.3(T)  indicates  M1.3  combined  with  a  Transfer  Profile  T1.3  or  T2.3.  M1.3(A)  means  Ml  .3  combined  with  the 
Access  Profile  A1.3. 


A.12.5  Functional  unit  field  detail 

See  8.1,  8.2,  part  9  table  7 


T1.3,  T2.3 

SERVICE  CLASSES 

Transfer 

Transfer  and  Management 

FUNCTIONAL  UNITS 

D 

T1.3,  T2.3 

D 

T1.3,  T2.3 

1 

Kernel 

m 

m 

m 

m 

2 

Read  (see  note  2) 

c 

o 

c 

o 

3 

Write  (see  note  2) 

c 

o 

c 

o 

4 

File  Access     

5 

Limited  File  Management 

0 

0 

m 

m 

6 

Enhanced 

File  Management 

0 

1 

0 

i 

7 

Grouping 

m 

m 

m 

m 

8 

FADU  Locking     

9 

Recovery 

0 

o 

0 

o 

10 

Restart 

0 

o 

0 

o 

NOTES 

1  The  recovery  and  the  restart  functional  units  are  only  available  at  the  internal  file  service  interface  and  should  only  be  explicitly 
referenced  in  the  protocol. 

2  The  c  indicates  that  either  or  both  of  the  read  and  write  functional  units  shall  be  implemented  in  the  particular  service  class. 
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A1.3 

FUNCTIONAL  UNITS 

SERVICE  CLASSES 
Access 
D  A1.3 

11 

Kernel 

m 

m 

12 

Read 

m 

m 

13 

Write 

m 

m 

14 

File  Access 

m 

m 

15 

Limited  File  Management 

0 

o 

10 

Enhanced 

File  Management 

0 

i 

17 

Grouping 

0 

o 

18 

FADU  Locking 

0 

o 

see  8.6.2 

19 

Recovery 

0 

0 

20 

Restart 

0 

o 

See  8.1 


M1.3(T)                                           SERVICE  CLASSES 

Transfer 

Management 

Transfer  and  Management 

FUNCTIONAL  UNITS          D  M1.3{T) 

D  M1.3(T) 

D 

M1.3(T) 

Kernel 

m  m 

m 

m 

Read 

c 

o 

Write 

c 

o 

File  Access     

Limited  File  Management       o  m 

m  m 

m 

m 

Enhanced 

File  Management                o  m 

0  m 

0 

m 

Grouping 

m  m 

m 

m 

FADU  Locking     

Recovery 

0 

o 

Restart 

0 

o 

NOTE  -  Ml. 3(1)  indicates  Ml. 3  in  conjunction  with  a  Transfer  Profile  T1.3  or  T2.3.  This  table  lists  only  the  additional  functionality 

as  defined  by  M1.3. 
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December  1990  (Stable) 


Ml. 3(A) 


FUNCTIONAL  UNITS 


See  8.1 


SERVICE  CLASSES 


Access 

D  M1.3(A) 


Management 

D  M1.3(A) 


Kernel 


m 


m 


32 


33 


34 


Read 


Write 


36 


37 


38 


39 


File  Access 


Limited  File 
Management 


Enhanced 

File  Management 


m 


m 


Grouping 

m  m 

FADU  Locking 

Recovery 

Restart 

NOTE  -  M1.3(A)  indicates  M1.3  in  conjunction  with  the  Access  Profile  A1.3.  This  table  lists  only  the  additional  functionality  as 
defined  by  Ml  .3. 


A.I  2.6  Diagnostic  field  detail 


D 

T1.3,  T2.3,  A1.3 

Ml. 3 

Diagnostic  type 

m 

m 

m 

Error  identifier 

m 

m 

m 

Error  observer 

m 

m 

m 

Error  source 

m 

m 

m 

Suggested  delay 

0 

c 

1         see  8.5.2 

Further  details 

0 

m 

m 

For  values  of  the  'further  details'  term  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1 
(GO  and  G1)  character  sets  is  required  (see  part  9  clause  13). 
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A.12.7  Contents  type  detail 

A.I  2.7.1  Contents  type  list  parameter 


See  part  9  10.2.1 


D  PROFILES 
1  R 

Maximum  number  of  elements 

document  type  specifications 
abstract  syntax  specifications 

0                      o  m 
0                      o  m 

A.1 2.7.2  Contents  type  parameter 

See  part  9  10.2.3 

D  PROFILES 

REFERENCE 

document  type  specifications 

0  m 

see  part  9  9.1 

abstract  syntax  /  constraint  set  pair 
specifications 

0  i 

HOTE  -  The  detail  of  document  types  supported  is  contained  in  clause  A.  13. 

A.I  2.8  FTAM  Quality  of  service  details 

See  8.5.2 

A.1 2.9  Details  of  shared  ASE  information 

( Void  ) 

A.1 2.10  Details  of  charging 

See  part  9  5.8  and  18.4 

Charging 

D  PROFILES 
R 

Resource  identifier  term 

m  m 

Charging  unit  term 

m  m 

Charging  value  term 

m  m 
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A.12.11  FiSestore  password  detaii 


Filestore  password  detail 

D 

PROFILES 

OctetString 

0 

o 

GraphicString 

0 

o 

A.I 2.1 2  Create  password  detail 

See  part  9  16.3 

Create  password  detail 

D 

PROFILES 

OctetString 

0 

o 

GraphicString 

0 

o 

A.I  2.1 3  Concurrency  control 

A.12.13.1  Supported  values 

See  8.6.1 

T1.3 

not  required 

shared 

exclusive 

no  access 

Action 

D  T1.3 

D 

T1.3 

D 

T1 

3 

D  T1.3 

Read 

0  o 

0 

o 

0 

o 

o  o 

Insert 

0  i 

0 

0 

o  i 

Replace 

0  o 

0 

o 

0 

o 

0  o 

Extend 

0  o 

0 

o 

0 

o 

0  o 

Erase 

0  1 

0 

i 

0 

i 

0  i 

Read  attrib 

0  o 

0 

o 

0 

o 

o  o 

Change  attrib 

0  i 

0 

0 

1 

0  i 

Delete  file 

0  o 

0 

o 

0 

o 

0  o 
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T2.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

T2.3 

D 

T2-3 

D 

T2.3 

D  T2.3 

9 

0 

o 

Q 

Q 

0 

o 

0  o 

10 

InsGrt 

o 

o 

Q 

Q 

0 

o 

o  o 

11 

0 

o 

0 

O 

0 

o 

0  o 

12 

0 

o 

0 

o 

0 

o 

0  o 

13 

Er3S6 

0 

1 

\J 

1 

1 

0 

1 

o  i 

14 

0 

o 

0 

o 

0 

o 

0  o 

25 

Change  attrib 

0 

i 

0 

i 

o 

i 

0  1 

16 

Delete  file 

0 

o 

0 

o 

0 

o 

0  o 

A1.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

A1.3 

D 

A1.3 

D 

A1.3 

D 

A1.3 

17 

Read 

0 

o 

0 

o 

0 

o 

0 

o 

18 

Insert 

0 

o 

0 

o 

0 

o 

0 

o 

19 

Replace 

0 

o 

0 

o 

0 

o 

0 

o 

20 

Extend 

0 

o 

0 

o 

0 

o 

0 

o 

21 

Erase 

0 

o 

0 

o 

0 

o 

0 

o 

22 

Read  attrib 

0 

o 

0 

o 

o 

o 

o 

o 

23 

Change  attrib 

0 

0 

0 

o 

i 

24 

Delete  file 

0 

o 

0 

o 

0 

o 

o 

o 
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M1.3 

not  required 

shared 

exclusive 

no  access 

Acxion 

D 

M1.3 

n 

M  1  -O 

n         Mi  t 

U                M  1  .«3 

U                M  1  .J 

25 

Read 

o 

o 

I 

1 

0  i 

0  [ 

26 

Insert 

0 

0 

i 

0  1 

0  1 

27 

Replace 

0 

0 

1 
1 

0  i 

0  1 

28 

Extend 

0 

0 

1 

1 

0  i 

0  i 

29 

Erase 

0 

0 

0  i 

0  1 

30 

Read  attrib 

0 

o 

0 

o 

0  o 

0  o 

31 

Change  attrib 

0 

o 

0 

o 

0  o 

0  0 

32 

Delete  file 

o 

o 

0 

o 

0  o 

0  o 

A.I 2.13.2  Responder  Default  values 


See  8.6.1,  part  9  clause  14 


A.I 2.14  FADU  Locking 


A1.3 

not  required 

FADU  Locking  Support  Values 
shared 

exclusive 

no  access 

D 

A1.3 

D 

A1.3 

D 

A1.3 

D  A1.3 

1 

Read 

0 

o 

0 

o 

0 

0 

0  0 

2 

Insert 

0 

o 

0 

o 

0 

o 

0  o 

3 

Replace 

0 

o 

0 

o 

0 

o 

0  o 

4 

Extend 

0 

o 

0 

o 

0 

o 

0  o 

5 

Erase 

o 

o 

0 

o 

0 

o 

o  o 
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initiator  override 

D 

PROFiLES 
i 

1 

Create  failure 

0 

o 

2 

Select  old  file 

0 

o 

3 

Delete  and  reaeate  with  old  attributes 

0 

o 

4 

Delete  and  create  with  new  attributes 

0 

o 

NOTE  -  The  specification  of  the  role  of  responder  is  given  in  A.  10.5 


A.12.16  Requested  Access 


See  part  9  clause  15 


Action 

D 

T1.3 

T2.3 

A1.3 

M1.3 

1 

Read 

0 

o 

o 

o 

2 

Insert 

0 

1 

o 

o 

3 

Replace 

0 

o 

0 

o 

4 

Extend 

0 

o 

o 

o 

5 

Erase 

o 

1 

1 

o 

6 

Read  attribute 

0 

o 

o 

o 

m 

7 

Change  attribute 

0 

1 

1 

i 

m 

8 

Delete  file 

o 

o 

o 

o 

m 

A.12.17  Processing  mode 

Processing  mode 

D 

T1.3 

T2.3 

A1.3 

Ml. 3 

1 

Read 

0 

o 

o 

o 

2 

Insert 

0 

i 

o 

o 

3 

Replace 

o 

o 

o 

o 

4 

Extend 

0 

o 

o 

o 

5 

Erase 

0 

i 

i 

o 
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See  8.5.2 


Recovery  mode 

D 

T1.3,T2.3,  A1.3 

M1.3 

None 

0 

m 

1 

At  start  of  transfer 

0 

m 

1 

Any  active  checkpoint 

0 

o 
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Section  6  :  Document  Type  Detail 

A.13  Document  types 

See  7.1 

Conformance  to  document  types  is  given  at  two  levels.  The  following  table  indicates  which  document  types  have 
some  level  of  support.  The  detail  of  that  level  of  support  is  stated  in  the  following  tables. 


Entry  number 

FTAM-1  D 

T1.3 

T2.3  A1.3 

Ml. 3 

Object  descriptor 
Object  identifier 

ISO  FTAM  unstructured  text  o 
{iso  standard  8571  document-type(5)  unstructured-text(l)} 

m 

m  m 

see  A,  13.1 

i 

Entry  number 

FTAM-2  D 

T1.3 

T2.3  A1.3 

Ml. 3 

Object  descriptor 
Object  identifier 

ISO  FTAM  sequential  text  o 
{iso  standard  8571  document-type(5)  sequential-text(2)} 

i 

m  m 

see  A.  13.2 

i 

Entry  number 

FTAM-3  D 

11. 3 

T2.3  A1.3 

M1.3 

Object  descriptor 
Object  identifier 

ISO  FTAM  unstructured  binary  o 
{iso  standard  8571  document-type(5)  unstructured-binary(3)} 

m 

m  m 

see  A.  13.3 

i 

Entry  number 

FTAM-4  D 

T1.3 

T2.3  A1.3 

Ml. 3 

Object  descriptor 
Object  identifier 

ISO  FTAM  sequential  binary  o 
{iso  standard  8571  document-type{5)  sequential-binary(4)} 

i 

o  o 

see  A.  13.4 

i 

Entry  number 

NBS-6 

D 

T1.3      T2.3      A1.3   Ml. 3 

Object  descriptor 

NBS-6  FTAM  sequential  file 

i           o          o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  sequential(6) } 

see  A.  13.5 

Entry  number 

NBS-7 

D 

11. 3      T2.3      A1.3    Ml. 3 

Object  descriptor 

NBS-7  FTAM  random  access  file 

i           o           o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  random-file(7) ) 

see  A.  13.6 
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Entry  number 

NBS-8 

D 

T1.3      T2.3      A1.3   Ml. 3 

Object  descriptor 

NBS-8  FTAM  indexed  file 

i           o          o  j 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  indexed-file(8) } 

see  A.  13.7 

Entry  number 

NBS-9 

D 

T1.3      T2.3      A1.3   Ml. 3 

Object  descriptor 

NBS-9  FTAM  file  directory  file 

o          o          o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  file-directory (9) } 

see  part  9  18.3 

Entry  number 

NBS-10 

D 

T1.3      T2.3      A1.3    Ml. 3 

Object  descriptor 

NBS-10  FTAM  random  binary  access  file 

i           o          o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  random-binary(IO)  } 

see  7. 1 

Entry  number 

NBS-11 

D 

T1.3      T2.3      A1.3    Ml. 3 

Object  descriptor 

NBS-1 1  FTAM  indexed  file  witfi  unique  keys 

i           o          o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamslg(5) 

document-type(5)  indexed-file-with-unique-keys(1 1) } 

see  A.  13.8 

Entry  number 

NBS-1 2 

D 

T1.3      T2.3      A1.3    Ml. 3 

Object  descriptor 

NBS-1 2  NBS  FTAM  simple  text  file 

i           o          o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  simple-text-file(12) } 

see  A.  13.9 
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Constraint  sets  and  FADU  identities  for  document  types 


For  the  constraint  set  /  FADU  identity  tables  the  following  notation  is  used: 


mandatory 


optional 
not  supported 
not  applicable 
excluded 


in  the  constraint  set  definition,  or  optional  in  the  constraint  set  definition  but  shall  be  implemented  by  implementations 

claiming  conformance  to  the  Profile.  The  support  of  the  FADU  identity  will  be  dependent  on  the  actions  which  have 

been  implemented. 

in  the  constraint  set  definition 

(outside  the  scope  of  this  ISP,  may  be  Ignored) 

(not  defined  in  the  constraint  set  definition) 

(disallowed  in  the  document  type  definition  or  in  FTAM  Phase  3) 


Implementation  Profile  T1.3. 


FADU  Identity 
Constraint  Set 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node 
Seq 

Node 
Number 

FTAM  unstructured 
constraint  set 

m 

FTAM-1 

m 

FTAM-3 

m 

NBS-9 

m 
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Implementation  Profile  T2.3  (see  7.2,  part  9  clause  10) 


December  1990  (Stable) 


FADU  identity 
Constraint  Set 

Begin 

End 

First 

l-ast 

Current 

Next 

Previous 

Node 
Seq 

Node 
Number 

FTAM  unstructured 
constraint  set 

m 

FTAM-1 

m 

FTAM-3 

tn 

NBS-9 

m 

FTAM  sequential  flat 
constraint  set 

o 

o 

0 

o 

o 

o 

o 

o 

FTAM-2 

m 

m 

i 

i 

i 

i 

i 

FTAM-4 

m 

m 

i 

i 

i 

i 

NBS-6 

m 

m 

i 

X 

X 

i 

X 

X 

NBS-12 

m 

m 

X 

X 

X 

X 

X 

X 

FTAM  ordered  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

o 

o 

NBS-8 

m 

i 

i 

i 

i 

m 

i 

FTAM  ordered  flat  constr 
set  with  unique  names 

o 

o 

o 

o 

o 

o 

NBS-11 

m 

i 

m 

NBS  ordered  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

0  1 

NBS-7 

m 

m 

m 

m 

i 

i 

i 

m 

NBS  random  access 
constraint  set 

0 

o 

o 

o 

1  NBS-10 

m 

m 

m 

m  1 
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Implementation  Profile  A1.3  (see  pan  9  clause  10) 


December  1990  (Stable) 


FADU  Identity 
Constraint  Set 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node 
Seq 

Node 
Number 

FTAM  unstructured 
constraint  set 

- 

- 

m 

- 

- 

- 

- 

- 

FTAM-1 

m 

FTAM-3 

vn 

NBS-9 

m 

FTAM  sequential  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

°  1 

FTAM-2 

m 

m 

m 

i 

m 

i 

i 



FTAM-4 

m 

m 

m 

i 

m 

i 

NBS-6 

m 

m 

m 

X 

X 

m 

X 

X 

NBS-12 

m 

m 

m 

X 

X 

m 

X 

^  1 

FTAM  ordered  flat 
constraint  set 

Q 

o 

o 

o 

o 

o 

o 

o 

o 

NBS-8 

m 

m 

i 

i 

m 

m 

m 

m 

i 

FTAM  ordered  flat  constr 
set  with  unique  names 

o 

o 

o 

o 

o 

o 

o 

NBS-11 

m 

m 

m 

m 

m 

m 

i 

NBS  ordered  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

o 

NBS-7 

m 

m 

m 

m 

m 

m 

m 

m 

NBS  random  access 
constraint  set 

o 

o 

o 

o  1 

NBS-10 

m 

m 

m 

m 
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A.13.1  FTAM-1    (See  7.1) 

A.13.1.1  Universal  class  number  parameter  (See  part  9  10.1) 

D 

T1  1  TO  T   A1  1 

1 

Universal  class  number  parameter  supported 

0 

m 

2 

PrintableString    -            Universal  class  19 

o 

i 

3 

TeletexString      -            Universal  class  20 

0 

1 

4 

VideotexString    -            Universal  class  21 

o 

1 

5 

lASString          -            Universal  class  22 

0 

m 

see  part  9  10.1.1-2 

6 

GraphicString     -           Universal  class  25 

0 

m 

see  A.I  O.I  .3 

7 

VisibleString      -            Universal  class  26 

0 

m 

8 

GeneralString     -           Universal  class  27 

o 

m 

see  A.  13. 1.4 

A.I 3. 1.2  String  length  parameter  and  string  significance  parameter  combinations 

D 

T1.3,  T2.3,  A1.3 

1 

Maximum  string  length  parameter  and 
variable  length  strings 

0. 

m 

2 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

m 

3 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

4 

Unbounded  strings  and 
variable  length  strings 

0 

m 

5 

Unbounded  strings  and 
not  significant  strings 

0 

m 

A.1 3.1.3  G  sets  supported 

G  sets  which  are  supported  in  FTAM-1  GraphicString. 

1 

For  values  of  GraphicString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  is  required, 
(see  part  9  10.1.1  and  10.1.3) 
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A.13.1.4  G  and  C  sets  supported 

G  and  C  sets  which  are  supported  in  FTAM-1  GeneralString 


December  1990  (Stable) 


For  values  of  GeneralString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  and  ISO  646  IRV  (CO)  control  character  set  Is  required 
(see  part  9  10.1-3) 


A.13.2  FTAM-2       (see  7.1) 


A.I 3.2.1  Universal  class  number  parameter  (see  part  9  10.1) 


D 

T2.3,  A1.3 

Universal  class  number  parameter  supported 

0 

m 

PrintableString  - 

Universal  class  19 

0 

i 

TeletexString 

Universal  class  20 

0 

i 

VideotexString  - 

Universal  class  21 

0 

lASString 

Universal  class  22 

0 

o 

see  part  9  10.1.1-2 

Graph  icString 

Universal  class  25 

0 

m 

see  A.  13.2.3 

VisibleString 

Universal  class  26 

0 

m 

GeneralString 

Universal  class  27 

0 

o 

see  A.  13.2.4 

A.I 3.2.2  String  length  parameter  and  string  significance  parameter  combinations 

D 

T2.3,  A1.3 

Maximum  string  length  parameter  and 
variable  length  strings 

0 

i 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

1 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

Unbounded  strings  and 
variable  length  strings 

0 

Unbounded  strings  and 
not  significant  strings 

0 

m 
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A.1 3.2.3  G  sets  supported 


December  1990  (Stable) 


G  sets  which  are  supported  in  FTAM-2  Graph icString. 


For  values  of  GraphicString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  is  required, 
(see  part  9  10.1.1  and  10.1.3) 


A.13.2.4  G  and  C  sets  supported 

G  and  C  sets  which  are  supported  in  FTAM-2  GeneralString 


For  values  of  GeneralString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  and  ISO  646  IRV  (CO)  control  character  set  is  required, 
(see  part  9  10.1.1-3) 


A.1 3.3  FTAM-3 


A.I 3.3.1  String  length  parameter  and  string  significance  parameter  combinations  (see  7.1) 


D 

T1.3,  T2.3,  A1.3 

Maximum  string  length  parameter  and 
variable  length  strings 

0 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

i 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

Unbounded  strings  and 
variable  length  strings 

0 

Unbounded  strings  and 
not  significant  strings 

0 

m 
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A.I  3.4  FTAM-4  (see  7.1) 

A.I 3.4.1  String  length  parameter  and  string  significance  parameter  combinations 


D 

T2.3,  A1.3 

Maximum  string  length  parameter  and 
variable  length  strings 

0 

1 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

1 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

Unbounded  strings  and 
variable  length  strings 

0 

1 

Unbounded  strings  and 
not  significant  strings 

0 

m 
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A.13.5  NBS-6 
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See  part  9  tables  2,  3 

A.I  3.5.1  ParameterO 


D 

T2.3,  A1.3 

ParameterO  supported 

m 

Universal-time 

Universal  class  23 

m 

Generalized-time 

Universal  class  24 

m 

boolean 

Universal  class  1 

m 

null 

Universal  class  5 

m 

A.I  3.5.2  Parameterl 

(see  part  9  10.1) 

D 

T2.3,  A1.3 

Parameterl  supported  m 

integer 

Universal  class  2 

m 

bit 

Universal  class  3 

m 

IA5 

Universal  class  22 

m 

GraphicString 

Universal  class  25 

m 

GeneralString 

Universal  class  27 

m 

OctetString 

Universal  class  4 

m 

A.I  3.5.3  Parameter2 


D  T2.3,  A1.3 


Parameter2  supported  -  o 
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A.I  3.6.1  ParameterO 

See  part  9  tables  2,  3 

D 

T2.3,  A1.3 

1 

ParameterO  supported 

m 

2 

Universal-time 

1  Iniv/prQ^il  place  0"^ 

nn 

3 

Generalized-time 

Universal  class  24 

m 

4 

boolean 

Universal  class  1 

m 

5 

null 

Universal  class  5 

m 

A.I  3.6.2  Parameterl 

(see  part  9  10.1) 

D               T2.3,  A1.3 

1 

Parameterl  supported 

m 

2 

integer 

Universal  class  2 

m 

3 

bit 

Universal  class  3 

m 

4 

IA5 

Universal  class  22 

m 

5 

GraphicString 

Universal  class  25 

m 

6 

GeneralString 

Universal  class  27 

m 

7 

OctetString 

Universal  class  4 

m 

A.I  3.6.3  Parameter2 

D 

T2.3,  A1.3 

1 

Parameter2  supported 

o 
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A.13.7  NBS-8 


December  1990  (Stable) 


See  part  9  tables  2,  3 

A.1 3.7.1  ParameterO 


Data  Types 

D        T2.3,  A1.3 

Key  Type 

D       T2.3,  A1.3 

ParameterO  supported 

m 

m 

Universai-time 

Universal  ciass  23 

m 

m 

Generalized-time 

Universal  class  24 

m 

m 

boolean 

Universal  class  1 

m 

null 

Universal  class  5 

m 

A.1 3.7.2  Parameterl 

(see  part  9  10.1) 

Data  Types 

D        T2.3,  A1.3 

Key  Type 

D       T2.3,  A1.3 

Parameterl  supported 

m 

m 

integer 

Universal  ciass  2 

m 

m 

bit 

Universal  class  3 

m 

IA5 

Universal  class  22 

m 

m 

GraphicString 

Universal  class  25 

m 

m 

GeneralString 

Universal  class  27 

m 

m 

OctetString 

Universal  class  4 

m 

m 

A.1 3.7.3  Parameter2 

Data  Types 

D       T2.3,  A1.3 

Key  Type 

D         T2.3,  A1.3 

Parameter2  supported 

o 

o 
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A.13.8  NBS-11 
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See  part  9  tables  2,  3 

A.1 3.8.1  ParameterO 


Data  Types 

D       T2.3,  A1.3 

Key  Type 

D        T2.3,  A1.3 

ParameterO  supported 

m 

m 

Universai-time 

Universal  class  23 

m 

m 

Generalized-time 

Universal  class  24 

m 

m 

boolean 

Universal  class  1 

m 

null 

Universal  class  5 

m 

A.1 3.8.2  Parameterl 

(see  part  9  10.1) 

Data  Types 

D        T2.3,  A1.3 

Key  Type 

D       T2.3,  A1.3 

Parameter  1  supported 

m 

m 

integer 

Universal  class  2 

m 

m 

bit 

Universal  class  3 

m 

IA5 

Universal  class  22 

m 

m 

Graph  icString 

Universal  class  25 

m 

m 

GeneralStnng 

Universal  class  27 

m 

m 

OctetString 

Universal  class  4 

m 

m 

A.1 3,8.3  Parameter2 

Data  Types 

D        T2.3,  A1.3 

Key  Type 

D        T2.3,  A1.3 

Parameter2  supported 

o 

o 
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A.13.9  NBS-12    (see  7.1) 

A.13.9.1  Universal  class  number  parameter  (see  part  9  10.1) 


D 

T2.3,  A1.3 

1 

Universal  class  number  parameter  supported 

m 

2 

PrintableString               -            Universal  class  19               -  1 

3 

TeletexString                 -            Universal  class  20               -  i 

4 

VideotexString               -           Universal  class  21               -  i 

5 

lASString                     -           Universal  class  22 

m 

6 

GraphicString                 -            Universal  class  25 

m 

see  A,  13.9.5 

7 

VisibleString                  -            Universal  class  26 

m 

S 

GeneralString                -           Universal  class  27 

m 

see  A. 13.9. 6 

A.I  3.9.2  String  length  parameter 

D           T2.3,  A1.3 

Maximum  string  length  parameter  supported 

tn 

A.I 3.9.3  String  significance  parameter 

D 

T2.3,  A1.3 

1 

String  significance  parameter  supported 

m 

see  7.1  table  3(c) 

2 

Variable  length  strings  supported 

m 

3 

Fixed  length  strings  supported 

m 

A.I  3.9.4  Character  set  parameter 

D 

T2.3,  A1.3 

1 

Character  set  parameter  supported 

m 

see  7.1  table  3(c) 
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A.1 3.9.5  G  sets  supported 

G  sets  which  are  supported  in  NBS-12  GraphicString.  

For  values  of  GraphicString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  is  required, 
(see  part  9  10.1.1  and  10.1.3) 


A.1 3.9.6  G  and  C  sets  supported 

G  and  C  sets  which  are  supported  in  NBS-12  GeneralString.  

I      For  values  of  GeneralString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  set  and  ISO  646  IRV  (CO)  control  character  sets  is  required, 
(see  part  9  10.1.1-3) 


-  END  OF  FTAM  PHASE  3  PROFILES  REQUIREMENTS  LIST  - 


t 
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Annex  B 
(normative) 

NIST  OIW  Register  of  FTAM  Objects 


BJ.  Introduction 

This  Index,  the  NIST  OIW  Register  of  OIW  FTAM  objects,  contains  a  complete  list  of  all  FTAM  objects  as  defined 
by  NIST  OIW. 

NIST  OIW  was  authorized  by  BSI  in  its  letter  dated  August  09,  1989,  as  Registration  Authority  for  NIST  OIW  defined 
objects.  The  Object  Identifier  Prefix  for  OIW  is 

{ iso(1)  identified-organization(3)  oiw(14) } 

NIST  OIW  Plenary  has  delegated  the  authority  and  the  task  for  maintenance  of  the  NIST  OIW  Register  of  FTAM 
objects  to  its  FTAM  Special  Interest  Group  (SIG)  at  its  meeting  on  September  15,  1989.  The  Object  Identifier  Prefix 
for  the  FTAM  SIG  is 

{  iso(1)  identified-organization(3)  oiw(14)  ftamsig(5) } 

For  each  new  OIW  FTAM  object  to  be  registered,  a  complete  technical  definition,  that  describes  the  purpose,  scope 
and  the  unique  characteristics  of  the  object,  must  be  prepared  and  presented  to  OIW  FTAM  SIG  for  technical 
discussion  and  acceptance,  and  for  final  approval  by  OIW  Plenary. 
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Index  of  QIW  FTAM  Objects 

FTAM  Phase  2  Defined  Ob|ects 


March  1991  (Stable) 


Object  Identifier  Prefix  :    nist-adhoc  ::=  {iso(1)  identified-organization(3)  icd(9999)  organization-code(l)} 


Object 

Object  Descriptor 

Object  Identifier 

Date  of 
Registration 

Reference  to 
Definition 

MDC  e 
NBo-D 

INDO-D  r  1  rtivl 

sequential  file 

tnisi-aunoc 
document-type(5) 
sequential(6) } 

uec  15,  oy 

Withdrawn 
March  16,  "90 

Stable  Agreements 

Vers.  4,  Ed.  1,  December  '90 

NISI  SP  500-183 

part  9,  annex  A  clause  A.I 

MPC  7 

iNDo-/  r  1  MM  ranaom 
access  file 

tnisi-aanoc 
document-type(5) 
random-file(7) } 

Uec  15,  89 

Withdrawn 
fwlarch  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1,  December  '90 

NISTSP  500-1 83 

part  9,  annex  A  clause  A.2 

MDC  Q 

Nbo-o 

MOO  Q  CTAkA 
Nbo-o  r  1  AM 

indexed  file 

{nist-adhoc 
document-type(5) 
indexed-file(8) } 

Uec  15,  89 

Withdrawn 
March  1 6,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NISTSP  500-183 

part  9,  annex  A  clause  A.3 

Kipo  Q  PTAM  filo 
iNDo-y  r  1  MM  me 

directory  file 

|nisi-aunuc 
document-type(5) 
file-directory(9) } 

uec  15,  oy 

Withdrawn 
March  1 6,  '90 

oiauie  Mgreemenis 

Vers.  4,  Ed.  1,  December  '90 

NISTSP  500-183 

part  9,  annex  A  clause  A.4 

KIR^  rtrHorari  flat 

constraint  set 

^1  liol  ClUI  lULr 

constraint-set(4) 
nbs-ordered-flat(l) } 

Han  1 1;  'flQ 
UQC  1  o,  oy 

Withdrawn 
March  16,  '90 

QtaKIo  An ante 
OLctUtc  MUl  eel  I  lol  1  Lo 

Vers.  4,  Ed.  1,  December  '90 

NISTSP  500-183 

part  9,  annex  B  clause  B.I 

NBS-AS1 

NBS  abstract 
syntax  AS1 

{nist-adhoc 
abstract-syntax(2) 
nbs-asl(l) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1,  December  '90 

NISTSP  500-183 

part  9,  annex  C  clause  C.I 

NBS-AS2 

NBS  file  directory 
entry  abstract  syntax 

{nist-adhoc 
abstract-syntax(2) 
nbs-as2(2) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1,  December  '90 

NISTSP  500-1 83 

part  9,  annex  C  clause  C.2 

AP-Title 

{nist-adhoc 
ftam-nil-ap-title(7) } 

Dec  15,  '89 

Stable  Agreements 

Vers.  4,  Ed.  1,  December  '90 

NIST  SP  500-183 

part  5  12.1.1.1 
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:=  {iso(1)  identified-organi2ation(3)  oiw(14)  ftamsig(5)} 


UDjeci 

Object  Descriptor 

vjojeci  laeniiTier 

Date  of 
Registration 

Reference  to 
Definition 

NBS-6 

NBS-6  FTAM 
sequential  file 

{nist-oiw-ftam 
document-type(5) 
sequential(6) } 

March  1 6,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NIST  SP  500-183 

part  9,  annex  A  clause  A.5 

NBS-7 

NBS-7  FTAM  random 
access  file 

{nist-oiw-ftam 
document-type(5) 
random-file(7) } 

March  1 6.  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NISTSP  500-183 

part  9,  annex  A  clause  A.6 

NBS-8 

NBS-8  FTAM 
indexed  file 

{nist-oiw-ftam 
document-type(5) 
indexed-file(8) } 

March  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1,  December  '90 

NIST  SP  500-183 

part  9,  annex  A  clause  A.7 

NBS-9 

NBS-9  FTAM  file 
directory  file 

{nist-oiw-ftam 
document-type(5) 
file-directory(9) } 

March  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NIST  SP  500-183 

part  9,  annex  A  clause  A.8 

NBS  ordered  flat 
constraint  set 

{nist-oiw-ftam 
constraint-set(4) 
nbs-ordered-flat(1 ) } 

March  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NISTSP  500-183 

part  9,  annex  B  clause  B.2 

NBS-AS1 

NBS  abstract 
syntax  AS1 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-asl(l) } 

March  1 6.  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NIST  SP  500-183 

part  9,  annex  C  clause  C.3 

NBS-AS2 

NBS  file  directory 
entry  abstract  syntax 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-as2(2) } 

March  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NISTSP  500-1 83 

part  9,  annex  C  clause  C.4 
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Object  Identifier  Prefix  :    nist-oiw-ftam  :=  iso(1)  identified-organization(3)  oiw(14)  ftamsig(5) 


Object 

Object  Descriptor 

Object  Identifier 

Date  of 
Registration 

Reference  to 
Definition 

NBS-10 

NBS-10  random 
binary  access  file 

{nist-oiw-ftam 
document -type(5) 
random-binary(IO) } 

Dec  15,  '89 

Stable  Aqreements 

Vers.  4,  Ed.  1 ,  December  '90 

NIST  SP  500-183 

part  10,  annex  C  clause  C.I 

NBS-11 

NBS-11  FTAM  indexed 
file  with  unique  keys 

{nist-oiw-ftam 
document-type(5) 
indexed-file-with-unique- 
l<eys(11) } 

Dec  15,  '89 

Stable  Aqreements 

Vers.  4,  Ed.  1 ,  December  '90 

NISTSP  500-183 

part  10,  annex  C  clause  C.2 

NBS-12 

NBS-12  FTAM 
simple  text  file 

{nist-oiw-ftam 
document-type(5) 

simple-text-file(12) } 

Dec  15,  '89 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NISTSP  500-183 

part  10,  annex  C  clause  C.3 

NBS  Random  Access 

{nist-oiw-ftam 
constraint-set(4) 
nbs-random-access(2) } 

Dec  15,  '89 

Stable  Aqreements 

Vers.  4,  Ed.  1 ,  December  '90 

NIST  SP  500-183 

part  10,  annex  D  clause  D.I 

NBS-AS3 

NBS  random  access 
node  name  abstract 
syntax 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-node-name(3) } 

Dec  15,  '89 

Stable  Aqreements 

Vers.  4,  Ed.  1 ,  December  '90 

NIST  SP  500-183 

part  10,  annex  E  clause  E.I 

NBS-AS4 

NBS  random  binary 
access  file 
abstract  syntax 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-random-binary(4) } 

Dec  15,  '89 

Stable  Aqreements 

Vers.  4,  Ed.  1,  December  '90 

NIST  SP  500-183 

part  10,  annex  E  clause  E.2 

NBS-AS5 

NBS  simple  text 
abstract  syntax 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-simple-text(5) } 

Dec  15,  '89 

Stable  Agreements 

Vers.  4,  Ed.  1,  December  '90 

NIST  SP  500-183 

part  10,  annex  E  clause  E.3 

67 


PART  10  -  ISO  FTAM  PHASE  3 


March  1991  (Stable) 


Annex  C  (normative) 
Document  Types 

C.1      NBS-10  Random  Binary  Access  File 
C.1.1       Entry  Number:  NBS-10 
C.I. 2       Information  objects 
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Table  4  -  Information  objects  in  NBS-10 


document  type  name 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 
random-binary(  1 0) } 

'NBS-10  FTAM  random  binary  access  file" 

abstract  syntax  names: 

a)  name  of  asnamel 

b)  name  of  asname2 

c)  name  of  asnameS 

{iso  identified-organization  oiw{14)  flamsig(5)  abstract-syntax(2) 
nbs-random-binary(4) } 

"NBS  random  binary  access  file  abstract  syntax"  {iso  standard 
8571  abstract-syntax(2)  ftam-fadu(2)} 
"FTAM  FADU" 

{iso  identified-organization  oiw(14)  ftamsig(5) 

abstract-syntax(2)  nbs-node-name(3) } 

"NBS  random  access  node  name  abstract  syntax" 

transfer  syntax  names: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  encoding  of  a  single  ASN.1  type" 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  identified-organization  oiw(14)  ftamsig(5) 
constraint-set(4)  nbs-random-access(2) } 
"NBS  random  access  constraint  set" 

File  contents: 

Datatypel  ::=  OCTET  STRING 

Datatype2  ::=  Node^iName 
-The  type  to  be  used  for  Node^iName  is  defined  in  ISO  8571 -FADU 
-The  only  Choice  for  Nodei^Name  is  user-coded 

Datatypes  ::  =  NBS-Node-Name 
-As  defined  by  the  NBS  Random  Access  NodelName  Abstract  Syntax 

C.I. 3       Scope  and  field  Of  application 

This  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  by  FTAM. 
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C.1.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer, 
Access  and  Management 


C.1 .5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 


C.I. 6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 


C.1 .7       Document  semantics 

The  document  consists  of  zero,  one,  or  more  File  Access  Data  Units.  Each  FADU  contains  precisely  one 
data  unit  which  consists  of  precisely  one  data  element.  The  data  element  is  made  up  of  one  octet.  The 
order  of  each  of  these  elements  is  significant.  The  semantics  of  the  data  elements  is  not  specified  by 
this  document  type. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as 
constrained  by  the  NBS  random  access  constraint  set.  The  definition  for  FTAM  hierarchical  file  model 
appears  in  8571  -2. 

There  are  no  size  or  length  limitations  imposed  by  this  definition. 


C.1. 8 


Abstract  syntactic  structure 


The  abstract  syntactic  structure  of  the  document  is  a  series  of  octets. 


C.1. 9 


Definition  of  transfer 
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C.I  .9.1        Datatype  definition 

The  presentation  data  value  used  for  transfer  is  an  ASN.1  OCTET  STRING. 

Datatype2  is  used  to  specify  the  FADU-ldentity  of  "name-list"  in  the  FTAM  PDUs  specifying  FADU- 
Identity,  where  "name-list"  is  defined  as  a  SEQUENCE  of  EXTERNAL.  The  EXTERNAL  is  defined  as 
Node-Name  in  the  FTAM  FADU  abstract  syntax.  The  use  of  Datatype2  is  defined  in  "NBS  random 
access  constraint  set." 
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Datatypes  specifies  tiie  "user-coded"  form  of  tlie  Node|Name  in  the  FTAM  FADU  abstract  syntax,  whiere 
"user-coded"  is  defined  as  an  EXTERNAL.  That  EXTERNAL  is  defined  by  Datatypes.  The  use  of 
Datatypes  is  defined  in  "NBS  random  access  constraint  set." 


The  document  is  transmitted  as  a  series  of  presentation  data  values.  Each  presentation  data  value  shall 
consist  of  the  "data"  from  one  or  more  FADUs  concatenated  together.  The  result  is  one  value  of  the 
ASN.1  data  type  OCTET  STRING.  The  "fadu-count"  field  supplied  in  the  NodeiName  specifies  the 
number  of  FADUs  to  transfer  during  a  Read  operation.  The  requested  FADUs  may  be  transferred  as  one 
or  more  presentation  data  values. 

All  values  are  transmitted  in  the  same  (but  any)  presentation  context  established  to  support  the  abstract 
syntax  name  "asnamel "  declared  in  table  4. 

NOTE  -  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be 
used,  when  the  above  permits  a  choice. 

Boundaries  between  P-DATA  primitives  and  between  presentation  data  values  are  chosen  locally  by  the 
sending  entity  at  the  time  of  transmission.  The  boundaries  are  not  preserved  when  the  file  is  stored  and 
they  carry  no  semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall 
accept  a  document  with  any  of  the  permitted  transfer  options. 


The  sequence  of  presentation  data  values  is  the  same  as  the  sequence  of  Data  Units  within  the  file. 

C.1.10     Transfer  syntax 

An  implementation  supporting  these  document  types  shall  support  the  transfer  syntax  generation  rules 
named  in  table  4  for  all  presentation  data  values  transferred. 

Implementations  may  optionally  support  other  transfer  syntaxes. 
C.I. 11      ASE  Specific  Specifications 

C.1.11.1       Simplification  and  rolaxation 

1  The  document  type  NBS-10  may  be  simplified  to  the  document  type  FTAM-3.  The  resultant  document 
contains  the  same  sequence  of  data  values  as  would  result  from  accessing  the  file  as  an  NBS-10  file. 


0.1.9.2 


Presentation  data  values 


0.1.9.3 


Sequence  of  presentation  data  values 
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A  READ  operation  may  be  applied  to  a  range  of  FADUs  via  the  FADU-ldentity  of  "NodeSeq".  Tfie 
"starting-fadu"  part  of  the  node  name  specifies  the  node  number  of  the  first  FADU;  the  "fadu-count" 
specifies  the  number  of  consecutive  FADUs  to  be  transferred. 

A  READ  operation  applied  to  a  range  of  FADUs  that  spans  beyond  the  end  of  file  is  valid.  All  available 
data  in  the  range  is  transferred.  An  informative  diagnostic  (5005)  is  returned  on  the  F-Data-End  request 
indicating  that  the  end  of  file  was  reached  and  a  portion  of  the  request  was  satisfied. 


C.I  .1 1 .3      The  REPLACE  operation 

When  the  REPLACE  operation  is  applied  to  the  root  FADU  of  an  NBS-10  document,  the  transferred  data 
shall  be  any  NBS-10  document. 

The  REPLACE  operation  applied  to  a  FADU-ldentity  of  "node  number"  is  used  to  replace  a  series  of 
FADUs,  starting  at  the  specified  position  in  the  file,  by  the  new  FADUs  being  transferred.  The  number  of 
replaced  FADUs  is  determined  by  the  number  of  transferred  FADUs. 

If  the  replacement  spans  beyond  the  end  of  the  existing  file,  then  the  additional  FADUs  are  inserted  at 
the  end  of  the  file. 


C.I  .1 1 .4      The  INSERT  operation 

When  the  INSERT  operation  is  applied  at  the  end  of  file,  the  transferred  data  shall  be  a  series  of  FADUs 
which  would  be  generated  by  reading  any  NBS-10  document  type  in  access  context  UA. 
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C.2     NBS-11  Indexed  File  With  Unique  Keys 
C.2.1       Entry  Number:  NBS-11 
C.2.2       Information  objects 
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Table  5 

-  Information  objects  In  NBS-11 

document  name 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 

indexed-file-witli-unique-keys(1 1 ) } 

"NBS-11  FTAM  indexed  file  with  unique  keys" 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract  syntax(2) 
nbs-asl(l)} 

"NBS  abstract  syntax  ASl" 

{iso  standard  8571  abstract-syntax(2)  ftam-fadu(2)} 
"FTAM  FADU" 

transfer  syntax  names: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  Encoding  of  a  single  ASN.1  type" 

parameter  syntax: 
PARAMETERS  ::=  SEQUENCE  { 

DataTypes, 

KeyType, 

KeyPosition  } 
DataTypes  ::=  SEQUENCE  OF  CHOICE  { 

ParameterO, 

Parameter  1 , 

Parameter2  } 
KeyType    ::=  CHOICE  { 

ParameterO, 

Parameter  1 , 

Parameter2  } 

-  ParameterO,  Parameterl ,  Parameter2,  as 

-  defined  for  the  document  types  NBS-6, 

-  NBS-7,  NBS-8 

KeyPosition::  =  INTEGER 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model' 

constraint  set 

{iso  standard  8571  constraint-set(4) 
ordered-flat-unique-names(4) } 
"FTAM  ordered  flat  constraint  set  with  unique  names" 

file  contents: 
Datatypel  ::=  PrimType 

-  as  defined  in  Annex  OC,  NBS-ASt 

C.3  of  NIST  SP  600  183 
Datatype2  ::=  CHOICE  { 

Node-Descriptor-Data-Element, 

Enter-Subtree-Data-Element, 

Exit-Subtree-Data-Element  } 
Datatypes^  «  Prtm  Typs   as  d^ned  by  the  NBS  ab^ract  syntax  ASl 
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C.2.3      Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  using  FTAM. 
NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 

C.2.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer, 
Access  and  {Management 

C.2.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 

C.2.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 

I  C.2.7       Document  semantics 

The  document  consists  of  zero,  one,  or  more  File  Access  Data  Units.  Each  FADU  consists  of  precisely 
I  one  data  unit  which  consists  of  zero,  one,  or  more  data  elements.  The  order  of  each  of  these  elements 
i  is  significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as 
i  constrained  by  the  FTAM  ordered  flat  constraint  set  with  unique  names  (see  table  5).  These  definitions 
:  appear  in  ISO  8571-2. 

[■  The  following  additional  requirements  are  specified  for  the  use  of  the  ordered  flat  constraint  set  with 
unique  names: 

The  FADU  identity  'node  number'  is  not  required  for  conformant  implementations 

The  Identities  'next'  and  'previous'  are  allowed  for  all  FADUs 

Each  data  element  is  a  data  type  from  the  set  of  primitive  data  types  defined  in  part  9  Annex  C,  NBS 
abstract  syntax  ASl .  Each  data  unit  contains  the  same  data  element  types  in  the  same  order  as  all 


!  other  data  units.  These  types  and  their  respective  maximum  lengths  are  defined  by  the  <DataTypes> 
parameter. 
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For  Datatypel  and  Datatypes,  the  string-length  field  of  Parameterl  specifies  the  length  of  the  value  in 
octets  for  the  INTEGER,  BIT  STRING  and  OCTET  STRING  types.  For  character-type  data  elements,  the 
string-length  indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  including 
any  escape  sequences  or  overhead  from  the  character  encoding. 

For  floating  point  numbers,  finite  form,  length-1  and  length-2  specify  the  length  in  bits  of  mantissa  and 
exponent,  respectively.  The  length-1  and  length-2  values  are  irrelevant  for  the  other  choices  of  floating 
point  numbers. 

Each  data  unit  in  the  file  has  a  key  associated  with  it,  which  is  the  user-coded  form  of  Node-Name.  The 
key  of  each  data  unit  is  of  the  same  data  type  as  the  key  of  all  other  data  units  in  the  file  and  is  a  single 
data  element  from  the  set  of  primitive  data  types  defined  in  part  9  Annex  C,  C.3  of  NIST  SP  500-183. 

The  type  and  length  of  the  key  are  defined  by  the  <KeyType>  parameter. 

The  primitive  data  types  and  minimum  size  ranges  of  each  unit  which  an  implementation  must  accept 
as  a  key  value  are  given  in  the  following  table  8. 


Table  6  -  Datatypes  for  keys 


Key  Type 

Minimum 

Order 

Range 

(octets) 

ASN.1  INTEGER 

(1-2) 

increasing  numeric  value 

ASN.1  lASString 

(1-16) 

lexical  order 

ASN.1  GraphicString        ASN.1  GeneralString 

(1-16) 

lexical  order 

ASN.1  OCTET  STRING 

(1-16) 

lexical  order 

ASN.1  GeneralizedTime 

(1-16) 

increasing  value 

ASN.1  UniversalTime 

increasing  time  value 

NBS-AS1  FloatingPointN  umber 

increasing  time  value 

increasing  numeric  value 

The  position  of  the  key  in  the  data  unit  is  specified  by  the  <KeyPosition>  parameter. 
KeyPosition  =  0  implies  the  key  is  not  part  of  the  data 
KeyPosition  >  0  specifies  the  actual  data  element  in  the  data  unit. 


C.2.8      Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  file  as  defined  in  the 
ASN.1  module  IS08571-FADU  in  ISO  8571,  in  which  each  of  the  file  access  data  units  has  the  abstract 
syntactic  structure  of  NBS-ASI  as  defined  by  the  parameters. 
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C.2.9       Definition  of  transfer 


C.2.9.1        Datatype  definitions 

The  file  consists  of  data  values  which  are  of  oithor 

a)  Datatypel  defined  in  table  5,  where  the  PrimType  in  the  datatype  is  given  by  the  NBS-AS1 
definition;  or 

b)  Datatype2  defined  in  table  5,  which  is  the  ASN.1  datatype  declared  as  "Data-Element"  in  the 
ASN.1  module  IS08571-FADU;  or 

c)  Datatypes,  defined  in  Table  5.  which  specifies  the  user-coded  form  of  the  Node-Name  In  the 
FTAM  FADU  abstract  syntax,  where  user-coded  is  defined  as  EXTERNAL. 


C.2.9.2        Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is 

a)  one  value  of  the  ASN.1  datatype  "Datatypel."  carrying  one  of  the  data  elements  from  the 
document.  All  values  are  transmitted  in  the  same  (but  any)  presentation  context  established  to 
support  the  abstract  syntax  name  "asnamel "  or 

I  b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the  same  (but  any)  presentation  context 

j  established  to  support  the  abstract  syntax  name  "asname2.";  or 

c)  a  value  of  "Datatypes"  carrying  a  Key.  All  values  are  transmitted  in  the  same  (but  any) 
presentation  context  established  to  support  the  abstract  syntax  name  "asnamel". 

NOTES 

1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used, 
where  the  above  permits  a  choice. 

I 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 

[i  Boundaries  between  presentation  data  values  in  the  same  presentation  context,  and  boundaries  between 
f  P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  carry  no 
I  semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document 
with  any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 


C.2.9.3        Sequence  of  presentation  data  values 

!  The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of 
j  types  a)  and  b)  is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the 
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hierarchical  structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO 
8571-2. 


C.2.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules 
named  in  table  5  for  all  presentation  data  values  transferred.  Implementation  may  optionally  support 
other  named  transfer  syntaxes. 


C.2.1 1     ASE  Specific  Specifications 


C.2.11.1       Simplification  and  relaxation 

This  simplification  loses  information. 

The  document  type  NBS-1 1  may  be  accessed  as  a  document  type  FTAM-3  (allowed  only  when  reading 
the  file)  by  specifying  document  type  FTAM-3  in  the  <  contents  type>  parameter  In  <F-OPEN  request >, 
and  limiting  access  context  to  UA  on  F-READ. 

The  octet  representation  of  the  transferred  data  is  unpredictable.  It  will  usually  correspond  to  the  data 
values  as  stored  in  the  local  Real  Filestore  of  the  Responder. 

A  document  of  type  NBS-1 1  can  be  accessed  as  a  document  of  type  NBS-6  (allowed  only  when  reading 
the  file)  by  specifying  document  type  NBS-6  with  appropriate  data  type  parameters  in  the  <  contents 
type>  parameter  on  the  <F-OPEN  request>.  The  traversal  order  of  the  FADUs  must  be  maintained. 

NOTE  -  The  traversal  order  is  as  reading  the  file  as  NBS-1 1  in  key  order. 

A  document  of  type  NBS-1 1  may  be  accessed  as  a  document  of  type  NBS-8  (allowed  only  when  reading 
the  file)  by  specifying  document  type  NBS-8  in  the  < contents  type>  parameter  in  the  <F-OPEN 
REQUEST>. 


C.2.1 1 .2      Access  context  selection 

A  document  of  type  NBS-1 1  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the  FTAM 
ordered  flat  constraint  set  with  unique  names.  The  presentation  data  units  transferred  in  each  case  are 
those  derived  from  the  structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 
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C.2.11.3       The  INSERT  operation 

When  the  <  INSERT >  operation  is  applied^;  the  transferred  material  shall  be  the  series  of  FADUs  which 
would  be  generated  by  reading  any  NBS-11  document  with  the  same  parameter  values  in  access 
context  FA. 

A  transferred  FADU  whose  name  duplicates  that  of  an  already  existing  FADU  will  cause  the  <INSERT> 
operation  to  fail.  The  failure  shall  be  signalled  by  issuing  an  F-CANCEL  Request  with  a  corresponding 
diagnostic. 

C.2.11.4       The  EXTEND  operation 

This  operation  is  excluded  for  the  use  with  this  document  type. 


C.2.11.5       The  REPLACE  operation 

When  the  <  REPLACE >  operation  is  applied  with  FADU  Identity  'begin',  a  transferred  FADU  whose  name 
duplicates  that  of  a  previously  transferred  FADU  will  cause  the  <  REPLACE  >  operation  to  fail.  The 
failure  shall  be  signalled  by  issuing  an  F-CANCEL  Request  with  a  corresponding  diagnostic. 
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C.3      NBS-12  Simple  Text  File  Document  Type 
C.3.1        Entry  Number:  NBS-12 
C.3.2       Information  objects 
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Table  7  -  Information  objects  in  NBS-12 


document  type  names 

{iso  identified-organization  oiw/(14)  ftamsig(5)  document-type(5) 

Oil  llpl©-IeXI-Hl©^  1  ]■ 

"NBS-12  FTAM  simple  text  file" 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2) 

nbs-simple-text(5)} 

"NBS  simple  text  abstract  syntax" 

{iso  standard  8571  abstract-syntax(2)  ftam-fadu(2)} 
"FTAM  FADU" 

transfer  syntax  names: 

{joint-iso-ccitt  asnl  (1)  basic-encoding  (1)} 
"Basic  Encoding  of  a  single  ASN.1  type" 

Parameter  Syntax 
PARAMETERS  ::=  SEQUENCE{ 
universal-class-number    [0]  IMPLICIT  INTEGER, 
maximum-string-length    [1]  IMPLICIT  INTEGER, 
string-significance                     [2]  IMPLICIT  INTEGER 
{variable  (0), 
fixed  (1)}. 

character-set                [3]  IMPLICIT  OctetString  OPTIONAL} 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set(4)  sequential  flat(2)} 
"FTAM  sequential  flat  constraint  set" 

File  contents 

Datatypel  ::=  NBSfText 

-as  defined  in  the  NBS  Simple  Text 
-Abstract  Syntax  registration  entry 

Datatype2  ::=  Node-Descriptor-Data-Element 

C.3.3       Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  and  for  transfer  and  access  by  FTAM. 
N01^  -  Storage  refiars  to  apparent  storage  withm  the  virtual  filestore. 
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C.3.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer, 
Access  and  Management 

ISO  8824,  Information  Processing  Systems  -  Open  Systems  Interconnection-Specification  of 
Abstract  Syntax  Notation  1  (ASN.1). 

ISO  8825,  Information  Processing  Systems  -  Open  Systems  Interconnection-Basic  Encoding 
Rules  for  Abstract  Syntax  Notation  One  (ASN.1). 

ISO  6429,  Information  Processing  -  ISO  7-bit  and  8-bit  coded  character  sets-Additional  control 
functions  for  cfiaracter  imaging  devices. 


C.3.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1.  In  addition,  it  mal<es  use  of  the  terms  character  string,  graphics  character,  and  format  effector 
as  defined  in  document  type  registration  entry  "FTAM-2"  in  ISO  8571-2. 


C.3.6  Abbreviations 

FTAM    File  Transfer,  Access  and  Management 


C.3.7       Document  semantics 

This  document  consists  of  zero,  one  or  more  file  access  data  units.  ,  each  of  Each  FADU  consl^s  of 
precisely  one  data  unit  which  consists  of  one  character  string.  The  order  of  each  of  these  elements  is 
significant.  The  semantics  of  the  character  strings  is  not  specified  by  this  document  type. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as 
constrained  by  the  sequential  flat  constraint  set.  These  definitions  appear  in  ISO  8571-2.  As  additional 
constraintsi  FADU  identity  will  be  limited  to  the  following  values: 

a)  'begin'  and  'end'  when  using  the  Transfer  or  Transfer  and  Management  service  classes. 

b)  'begin',  'end',  'first',  and  'next'  when  using  the  Access  service  class. 

Each  character  string  consists  of  characters  from  the  character  set  defined  by  the  ASN.1  (ISO  8824) 
character  set  type  whose  universal  class  number  is  given  by  the  "universal-class-number"  parameter  and 
by  the  escape  sequences  contained  in  the  optional  "character-set"  parameter.  If  the  character  set  type 
allows  explicit  escape  sequences,  the  "character-set"  parameter,  if  present,  contains  escape  sequences 
which  designate  and  invoke  specific  character  sets.  If  the  "character-set"  parameter  is  not  present, 
character  sets  are  assumed  to  be  designated  and  invoked  as  specified  in  table  2  in  ISO  8825.  Character 
strings  shall  not  contain  escape  sequences. 
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There  are  no  size  or  length  limitations  imposed  by  this  definition,  except  those  specified  here.  Each 
character  string  is  of  a  length  determined  by  the  number  of  characters  given  by  the  "maximum-string- 
length"  parameter. 

NOTE  -  The  length  restriction  refers  to  the  number  of  characters  from  the  applicable  character  set,  not  to 
the  number  of  octets  in  the  encoding,  nor  to  the  line  length  in  any  rendition  of  the  document,  where  these 
are  different. 

The  exact  significance  of  the  character  strings  is  determined  by  the  "string-significance"  parameter.  If  its 
value  is  "variable,"  the  length  of  the  character  strings  is  less  than  or  equal  to  the  length  given.  If  the 
value  Is  "fixed,"  the  length  of  each  character  string  is  exactly  equal  to  the  length  given. 

If  the  document  is  interpreted  on  a  character  imaging  device  (outside  the  scope  of  ISO  8571),  the 
interpretation  depends  on  the  character  set  in  use. 

a)  If  the  character  set  contains  format  effectors,  they  shall  be  interpreted  as  defined  in  ISO 
6429;  end  of  string  and  end  of  file  access  data  unit  are  given  no  formatting  significance,  and  do 
not  contribute  to  the  document  semantics; 

b)  If  the  character  set  does  not  contain  format  effectors,  the  end  of  each  character  string  is 
Interpreted  as  implying  carriage  return  and  line  feed  formatting  actions  in  any  rendition.  The  end 
of  file  access  data  unit  is  given  no  formatting  significance  beyond  that  attached  to  the  end  of  the 
string  in  it. 


C.3.8       Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  file  as  defined  in  the 
ASN.1  modules  IS08571-FADU  and  ISO  8571 -CONTENTS  in  ISO  8571,  in  which  each  of  the  file  contents 
data  elements  has  the  abstract  syntactic  structure  of  "NBS  Simpio  Text."  "NBS-Text."* 
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C.3.9       Definition  of  transfer 


C.3.9.1        Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either 

a)  Datatypel  defined  in  table  7,  the  ASN.1  datatype  declared  as  "NBS-Text"  in  the  NBS  Simple 
Text  Abotract  Syntax  simple  teirt  lbstract  s^^     definition.  The  choice  in  "NBS-Text"  is 
deternnined  by  the  universal-class-number  parameter;  or 

b)  Datatype2  defined  in  table  7,  the  ASN.1  datatype  declared  as  "Data-Element"  in  the  ASN.1 
module  ISO  8571 -FADU. 


C.3.9.2        Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is  either 

a)  one  value  of  the  ASN.1  datatype  "Datatypel,"  carrying  one  of  the  character  strings  of  the 
document.  Each  character  shall  be  transmitted  using  one  of  the  character  sets  identified  by  the 
universal-class-number  parameter.  All  values  are  transmitted  in  the  same  (but  any)  presentation 
context  established  to  support  the  abstract  syntax  name  "asnamel"  declared  in  table  7,  or 

b)  one  value  of  the  ASN.1  datatype  "Datatype2."  All  values  are  transmitted  in  the  same  (but 
any)  presentation  context  established  to  support  the  abstract  syntax  name  "asname2"  declared 
in  table  7. 

NOTES 

1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used, 
where  the  above  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 

Boundaries  between  P-DATA  primitives  are  chosen  locally  by  the  sending  entity  at  the  time  of 
transmission,  and  carry  no  semantics  of  the  document  type.  Receivers  which  support  this  document 
type  shall  accept  a  document  with  any  of  the  permitted  transfer  options. 
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C.3.9.3 


Sequence  of  presentation  data  values 


The  sequence  of  presentation  data  values  of  type  {a)  and  the  sequence  of  presentation  data  values  of 
types  {a)  and  {b)  is  the  same  as  the  sequence  of  character  strings  within  a  Data  Unit,  and  Data  Units  in 
the  hierarchical  structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO 
8571-2. 


C.3.10     Transfer  syntax 

An  Implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules 
named  in  table  7  for  all  presentation  data  values  transferred. 


C.3.11      ASE  specific  specifications 


C.3.11.1       Simplification  and  relaxation 


C.3.11. 1.1  Simplification  to  FTAM-1 

This  simplification  loses  information. 

The  document  type  NBS-12  may  be  accessed  as  a  document  type  FTAM-1.  The  resultant  document 
contains  the  same  sequence  of  data  values  as  would  result  from  accessing  the  structured  text  file  in 
access  context  UA.  That  is,  only  the  presentation  data  values  in  the  abstract  syntax  "asnamel"  are 
present.  If  the  "character-set"  parameter  was  present  before  the  simplification,  its  contents  will  be  added 
to  the  beginning  of  each  string. 

NOTE  -  The  boundary  between  file  access  data  units  remains  a  boundary  between  strings,  but  any  special 
significance  given  to  it  is  lost. 


The  document  type  NBS-12  may  be  relaxed  to  the  document  type  FTAM-2.  If  the  "character-set" 
parameter  was  present  before  the  relaxation,  its  contents  will  be  added  to  the  beginning  of  each  string. 


C.3.11. 1.2 


Relaxation  to  FTAM-2 


C.3.11. 1.3 


Character  set  relaxation 


This  operation  loses  explicit  information  in  the  document  type  identification. 

A  document  of  type  NBS-12  may  be  relaxed  to  a  different  document  of  type  NBS-12  with 
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a  different  "universal-class-number"  parameter  value; 
a  different  "character-set"  parameter  value; 
different  values  for  both  of  these  parameters; 

a  different  "universal-class-number"  parameter  value  and  no  "character-set"  parameter  value;  or 

no  "character-set"  parameter  value. 

if  the  resultant  document  type  permits  all  characters  from  the  original  document  type.  If  this  relaxation 
involves  including  format  effectors  and  none  were  present  before  the  simplification,  the  characters 
"carriage  return"  and  "line-feed"  shall  be  added  to  the  end  of  each  string. 

NOTE  -  If  the  characters  "carriage  return"  and  "line  feed"  are  not  part  of  the  format  effectors,  the  formatting 
action  may  be  represented  by  "newline,"  or  some  other  implementation  specific  choice  if  there  is  no 
representation  of  "newline"  defined. 


C.3.11.1.4         String  length  relaxation 

This  operation  loses  explicit  information  in  the  document  type  identification. 

A  document  of  type  NBS-12  may  be  relaxed  to  another  document  type  NBS-12  with  a  larger  "maximum- 
string-length"  parameter. 


C.3.11.2       Access  context  selection 

A  document  of  type  NBS-12  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the 
sequential  flat  constraint  set.  The  presentation  data  units  transferred  in  each  case  are  those  derived 
from  the  structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


C.3.11.3       The  INSERT  operation 

When  the  INSERT  operation  is  applied  at  the  end  of  file,  the  transferred  material  shall  be  the  series  of 
FADUs  which  would  be  generated  by  reading  any  NBS-12  document  type  with  the  same  parameter 
values  in  access  context  FA. 
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Annex  D  (normative) 
Constraint  Sets 

D.1      NBS  random  access  constraint  set 


Table  8  -  Basic  constraints  in  the  NBS  Random  Access  Constraint  Set 


Constraint  set  descriptor 

"NBS  random  access  constraint  set" 

Constraint  set  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  constraint-set(4) 
nbs-random-access(2) } 

Node  names 

All  names  shall  be  of  the  same  type;  the  type  of  the  names 
and  an  ordering  of  the  names  shall  be  defined  when  reference 
is  made  to  the  constraint  set. 

File  access  actions 

Locate,  Read,  Insert,  Erase,  Replace 

Qualified  actions 

None 

Available  access  context 

UA 

Creation  state 

Root  node  without  an  associate  data  unit 

Location  after  open 

Root  node 

Beginning  of  file 

Root  node 

End  of  file 

No  node  selected 

Read  whole  file 

Read  in  access  context  UA  with  FADU-ldentity  of  "begin" 

Write  whole  file 

Transfer  a  series  of  leaf  FADUs  which  would  be  generated  by 
reading  the  whole  file  in  access  context  UA;  perform  the 
transfer  with  a  FADU  Identity  of  "end"  and  a  file  access  action 
of  "insert",  or  with  a  FADU  Identity  of  "begin"  and  an  action  of 
"replace,"  orwftfj  an  FADU  identtty  of  "node  number*  and  an 

action  of 'reii^ace^'  Here  "node  number"  identifies  the  first 
FADU  in  tho  preorder  traversal  sequence. 
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Table  9  -  Identity  constraints  in  the  NBS  Random  Access  Constraint  Set 


Action 

Begin 

End 

NodeSeq 

Node  number 

Locate 

leaf 

Read 

whole 

leaf 

Insert 

leaf 

Erase 

whole 

leaf 

Replace 

whole 

leaf 

NOTE  -  NodeSeq  =  A  sequence  of  NodefNames  with  a  single  member 


D.1.1       Field  of  application 

The  NBS  Random  Access  constraint  set  applies  to  files  which  are  structured  into  a  sequence  of 
individual  FADUs  and  to  which  access  may  be  made  randomly  by  NodeSeq.  The  structuring  of  the  file 
into  individual  FADUs  is  determined  by  the  NodeiName. 

D.I  .2       Basic  constraints 

The  basic  constraints  in  the  NBS  Random  Access  constraint  set  are  given  in  table  8. 
D.I. 3       Structural  constraints 

The  root  node  shall  not  have  an  associated  data  unit;  all  children  of  the  root  node  shall  be  leaf  nodes 
and  shall  have  an  associated  data  unit;  all  arcs  from  the  root  node  shall  be  of  length  one. 

D.I. 4       Action  constraints 

Insert:  the  insert  action  is  allowed  only  at  the  end  of  the  file,  with  FADU-ldentity  of  "end";  the  new  node 
is  inserted  following  all  existing  nodes  in  the  file.  The  location  following  the  insert  is  "end". 

Erase:  the  erase  action  is  allowed  at  the  root  node  to  empty  the  file,  with  FADU-ldentity  of  "begin".  The 
result  is  a  solitary  root  node  without  an  associated  data  unit.  Erase  with  the  FADU-ldentity  of  "node 
number"  means  truncation  of  the  file. 

Replace  whole  file:  the  FADU-ldentity  is  "begin"  and  the  complete  series  of  new  FADU  contents  is  sent. 

Replace  new  leaves:  the  FADU-ldentity  is  "node  number"  and  the  number  of  FADUs  being  replaced  is 
given  by  the  number  of  FADUs  sent. 
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D.I. 5      Identity  constraints 

The  FADU-ldentity  associated  with  the  file  action  shall  be  one  of  the  identities:  begin,  end,  Node 
Number  and  NodeSeq.  The  actions  with  which  these  identities  can  be  used  are  given  in  table  9. 
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Annex  E  (normative) 
Abstract  Syntaxes 


E.1      NBS  Node  Name  Abstract  Syntax 

Abstract  Syntax  Name 

{  iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-node-name(3)  } 

"NBS  random  access  node  name  abstract  syntax" 

This  is  an  abstract  syntax  for  tlie  user-coded  Nod^Name  In  the  FTAM  FADU  abstract  syntax. 
NBS-AS3  DEFINITIONS::  = 
BEGIN 

NBS-Node-Name::=  SEQUENCE 

{         starting-fadu  [0]  IMPLICIT  INTEGER, 
fadu-count  [1]  IMPLICIT  INTEGER  } 
--a  "fadu-count"  of  0  specifies  the 
-range  of  FADUs 

-beginning  at  "starting-fadu"  and 
-ending  at  "end  of  file" 

END 


For  this  abstract  syntax  the  following  transfer  syntax  wiH  can  be  used. 


{  joint-iso-ccitt  asn1(1)  basic-encoding(l)  } 
"Basic  Encoding  of  a  single  ASN.1  type" 
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E.2      NBS  Random  Binary  Access  File  Abstract  Syntax 

Abstract  Syntax  Name 

{  iso  identified-organization  oiw(1 4)  ftamsig(5)  abstract-syntax(2)  nbs-random-binary(4)  } 
"NBS  random  binary  access  file  abstract  syntax" 

This  is  an  abstract  syntax  for  the  transfer  of  the  file  contents  for  NBS  random  binary  files. 
NBS-AS4  DEFINITIONS::  = 
BEGIN 

NBS-Random  Binary  ::=  OCTET  STRING 
-contains  one  or  more  presentation  data  values 
--concatenated  together. 
-Each  presentation  data  value  is  defined  as 
-Datatypel  in  table  4. 

END 

For  this  abstract  syntax,  the  following  transfer  syntax  will  |||  be  used: 

{  joint-iso-ccitt  asn1(1)  basic-encoding(l)  } 
"Basic  Encoding  of  a  single  ASN.1  type" 


91 


PART  10  -  FTAM  Phase  3 


E.3      NBS  Simple  Text  Abstract  Syntax 

Abstract  Syntax  Name 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-simple-text(5)  } 

"NBS  simple  text  abstract  syntax" 

NBS-AS5  DEFINITIONS::  = 

BEGIN 

NBS-Text::=  CHOICE  { 

IA5String,--Universal  Class  22 
GraphlcString,  --Universal  Class  25 
VisibleString,  -Universal  Class  26 
GeneralString  -Universal  Class  27  } 

END 

For  this  abstract  syntax,  the  following  transfer  syntax  wiU  Odn  be  used: 


{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  encoding  of  a  single  ASN.1  type" 


September  1991  (Stable)  i 
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Annex  F  (normative) 

Delta  Protocol  Implementation  Conformance  Statement  (PICS)  Pro 
forma 

(Refer  to  the  Working  Implementation  Agreements.) 


93 


PART  10  -  FTAM  Phase  3 


September  1991  (Stable) 


Annex  G  (normative) 
Amendments  and  Corrigenda 

(Refer  to  the  Working  Implementation  Agreements.) 
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Foreward 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Directory  Services 
Special  Interest  Group  (DSSIG)  of  the  National  Institute  of  Standards  and  Technology 
(NIST)  Workshop  for  Implementors  of  Open  systems  Interconnection  (OSI).  See  Procedures 
Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above  mentioned  Workshop.  This 
part  replaces  the  previously  existing  chapter  on  Directory  Services  Protocol.  There  is  no 
significant  technical  change  from  this  text  as  previously  given. 
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0  Introduction 

This  is  an  Implementation  Agreement  developed  by  the  Implementor's  Workshop  sponsored 
by  the  National  Institute  of  Standards  and  Technology  to  promote  the  useful  exchange  of 
data  between  devices  manufactured  by  different  vendors.  This  agreement  is  based  on  and 
employs  protocols  developed  in  accord  with  the  OSI  Reference  Model.  While  this  agreement 
introduces  no  new  protocols,  it  eliminates  ambiguities  in  interpretations. 

This  is  an  Implementation  Agreement  for  the  OSI  Directory  based  on  the  ISO  and  CCITT 
documents  cited  in  clause  2  of  this  part  (hereafter  referenced  as  Directory  Documents). 
This  agreement  is  aligned  with  the  UNOFFICIAL  'FINAL'  version  of  the  X.500  Series 
of  Recommendations,  December  1988.  Where  technical  differences  between  the  ISO  and 
CCITT  versions  of  these  documents  exist  (e.g..  Transport  Requirements)  the  ISO  versions 
are  given  precedence.  Figure  1  displays  the  structure  of  this  Implementation  Agreement. 
References  to  corresponding  CCITT  documents  are  included  for  information. 


Directory  Access  Protocol 
(DAP) 


Directory  System  Protocol 
(DSP) 


Remote  Operations  Services  and  Protocols 
(CCITT  X.219  and  X.229/ISO  9072/1  and  9072/2) 


Association  Control  Services  and  Protocols 
(CCITT  X.217  and  X.227/ISO  8649  and  8650) 


Figure  1  -  Structure  of  this  Implementation  Agreement. 

The  Directory  User  Agents  (DUAs)  and  Directory  System  Agents  (DSAs)  provide  access 
to  The  Directory  on  behalf  of  humans  and  applications  such  as  Message  Handling  and  File 
Transfer,  Access,  and  Management.  See  clause  1  for  more  information  on  the  model  used 
in  the  Directory. 

This  document  covers  both  the  Directory  Access  Protocol  (DAP)  and  the  Directory  System 
Protocol(DSP)  defined  in  the  Directory  Documents.  A  good  working  knowledge  of  the 
Directory  Documents  is  assumed  by  this  chapter.  All  terminology  and  abbreviations  used 
but  not  defined  in  this  text  may  be  found  in  those  documents. 


1  Scope 

Centralized  and  distributed  directories  can  both  be  accommodated  in  this  Agreement  by 
the  appropriate  choice  of  protocols  and  pragmatic  constraints  from  those  specified.  Figure  2 
illustrates  a  centralized  directory  and  figure  3  illustrates  a  distributed  directory. 
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This  agreement  does  not  cover  interaction  between  co-located  entities,  such  as  a  co-resident 
DUA  and  DSA.  It  also  does  not  specify  the  interface  between  a  user  (person  or  application) 
and  a  DUA.  Bilateral  agreements  between  a  DUA  and  DSA  or  DSA  and  DSA  may  be 
implemented  in  addition  to  the  requirements  stated  in  this  document.  Conformance  to  this 
agreement  requires  the  ability  to  interact  without  the  use  of  bilateral  agreements  other  than 
those  required  in  the  Directory  Documents. 

The  logical  structure  of  the  Directory  Information  Base  (DIB)  is  described  in  the  Directory 
Documents.  The  manner  in  which  a  local  portion  of  the  DIB  is  organized  and  accessed  by 
its  DSA  is  not  in  the  scope  of  this  agreement. 

2    Normative  references 


ISO/IEC  9594-l:1990(E),  Information  Technology  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  1:  Overview  of  Concepts,  Models,  and  Services. 

ISO/IEC  9594-2: 1990(E),  Information  Technology  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  2:  Models. 

ISO/IEC  9594-3:1990(E),  Information  Technology  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  3:  Abstract  Service  Definition. 

ISO/IEC  9594-4:1990(E),  Information  Technology  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  4:  Procedures  for  Distributed  Operation. 

ISO/IEC  9594-5:1990(E),  Information  Technology  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  5:  Protocol  Specifications. 

ISO/IEC  9594-6:1990(E),  Information  Technology  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  6:  Selected  Attribute  Types. 

ISO/IEC  9594-7:1990(E),  Information  Technology  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  7:  Selected  Object  Classes. 

ISO/IEC  9594-8:1990(E),  Information  Technology  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  8:  Authentication  Framework. 
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Figure  2  -  Centralized  Directory  Model. 
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Figure  3  -  Distributed  Directory  Model. 
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3  Status 

This  version  was  completed  in  December  1990. 

4  Use  of  the  Directory 

Given  the  rapid  multiplication  and  expansion  of  OSI  applications,  telecommunication  sys- 
tems and  services,  there  is  growing  need  for  users  of  OSI  applications,  as  well  as  the  appli- 
cations themselves,  to  communicate  with  each  other.  In  order  to  facilitate  their  communi- 
cations, a  Directory  protocol,  as  referenced  in  these  agreements,  has  been  tailored  to  meet 
their  respective  needs. 

In  one  instance.  The  Directory  will  be  used  as  a  service  to  provide  humans,  in  an  on-line 
fashion,  rapid  and  easy  retrieval  of  information  useful  for  determining  what  telecommunica- 
tions services  are  available,  and/or  how  to  access,  and  address  their  correspondents.  Further, 
service  providers  offering  such  a  Public  Directory  may  also  use  this  service  internally  with 
other  various  telecommunications  services  (e.g.,  MHS)  for  the  proper  addressing  of  calls  or 
messages.  Likewise,  this  does  not  preclude  the  usage  of  these  agreements  to  similarly  gener- 
ate a  privately  operated  Directory  that  supports  both  human  and  application  information 
exchanges. 

In  another  instance,  The  Directory,  will  be  used  as  a  service  by  computer  applications 
without  direct  human  involvement.  One  important  service  is  to  provide  Presentation  Ad- 
dress resolution  for  named  objects,  on  behalf  of  OSI  applications.  The  Directory  may  be 
used  by  applications  to  search  for  objects  (i.e..  Application  Entities),  without  direct  human 
involvement,  by  the  use  of  the  "search"  or  "list"  operations. 

To  support  the  many  possible  usages,  The  Directory  is  a  general  purpose  system.  It  is 
capable  of  storing  data  of  many  different  forms  as  attributes  within  entries,  and  is  also 
capable  of  supporting  simple  or  complex  hierarchical  structures,  with  variations  in  structure 
possibly  occurring  between  one  part  of  The  Directory  and  another. 

Compliant  DSA  implementations  should  safeguard  this  generality,  where  possible,  by  placing 
the  minimum  of  restrictions  in  "hard-wired"  form. 

5  Directory  ASEs  and  Application  Contexts 

This  clause  highlights  the  ASEs  (Application  Service  Elements)  and  Application  Contexts 
defined  in  the  Directory  Documents  and  of  concern  in  these  Agreements.  The  functionality 
of  the  Directory  AEs  (DUAs  and  DSAs)  is  defined  by  a  set  of  ASEs,  each  Directory  ASE 
specifying  a  set  of  Directory  operations. 

The  interaction  between  these  AEs  is  described  in  terms  of  their  use  of  ASEs.  This  specific 
combination  of  a  set  of  ASEs  and  the  rules  for  their  usage  defines  an  application  context. 

The  following  ASEs  are  described  in  the  Directory  Documents: 

-  Read  ASE 

-  Chained  Read  ASE 
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-  Search  ASE 

-  Chained  Search  ASE 

-  Modify  ASE 

-  Chained  Modify  ASE 

ROSE  and  ACSE  also  form  part  of  the  Directory  Application  Contexts. 

The  following  Application  Contexts  are  described  in  the  Directory  Document: 

-  Directory  Access  Application  Context 

-  Directory  System  Application  Context 

6  Schema 

There  are  seven  (7)  major  topics  that  relate  to  schema: 

6.1  Support  of  Structures  and  Naming  Rules 

DSAs  shall  be  capable  of  supporting  (subject  to  refinements  laid  down  in  these  Agreements) 
the  structure  and  naming  rules  defined  in  the  Directory  Documents,  Part  7,  Annex  B. 

Part  7,  Annex  B  of  the  Directory  Documents  provides  a  framework  for  the  basic  use  of  the 
Directory  in  terms  of  the  objects  defined  in  Part  7.  It  does  not,  however,  form  part  of  the 
standard  and,  in  any  case,  permits  structures  and  practices  which  may  be  undesirable.  The 
guidelines  below  provide  tighter  control  within  the  Annex  B  framework. 

It  is  recommended  that  only  an  entry  subordinate  to  Root  or  Country  may  use  a  StateOr- 
ProvinceName  AVA  as  an  RDN. 

6.2  Support  of  Object  Classes  and  Subclasses 

The  DSAs  shall  be  able  to  support  all  superclasses  of  the  supported  object  classes  (e.g.. 
Top,  Person). 

Use  of  an  object  class  in  this  profile  or  the  standard  (or  a  subclass  derived  from  one  or 
more  of  these  object  classes)  is  recommended  wherever  the  semantics  are  appropriate  for 
the  application.  The  derivation  of  a  new  object  class  as  an  immediate  subclass  of  Top  should 
be  avoided.  For  example,  to  represent  printers  in  the  Directory,  one  can  derive  a  subclass 
of  Device. 

An  entry  of  a  particular  object  class  may  contain  any  optional  attribute  listed  for  it  in 
the  Directory  Documents;  a  conformant  DSA  shall  be  able  to  support  all  these  optional 
attributes. 

In  addition,  a  DSA  may  permit  any  locally  registered  attribute,  or  a  subset  of  these,  by  pro- 
viding the  local  extension  facilities  permitted  by  unregistered  object  classes  (viz.  Directory 
Documents,  Part  2,  clause  9.4.1  (a)  and  Note). 


1- 
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6.3  Support  of  Attribute  Types 

DSAs  shall  be  able  to  support  the  storage  and  use  of  attribute  type  information,  as  defined 
in  the  Directory  Documents,  Part  6,  including  their  use  in  naming  and  access  to  entries; 
they  shall  also  support  the  definition  of  new  attribute  types,  making  use  of  pre-existing 
attribute  syntaxes. 

DSAs  shall  support  the  encoding,  decoding,  and  matching  of  all  the  attributes  in  the  Naming 
Prefixes  of  every  naming  context  they  hold  (ref  Directory  Documents,  Part  4,  clause  9). 
These  attributes  may  include  attributes  that  are  not  permitted  to  appear  in  entries  in  those 
naming  contexts. 

6.4  Support  of  Attribute  Syntaxes 

Suggested  methods  for  the  interpretation  of  selected  Attribute  Syntaxes  are  defined  in  annex 
A. 

6.5  Naming  Contexts 

The  root  of  a  naming  context  shall  not  be  an  alias  entry. 

6.6  Common  Profiles 

This  subclause  identifies  profiles  that  are  commonly  useful  for  various  applications  while  an 
application-specific  profile(s)  is  identified  by  the  application. 

6.6.1     OIW  Directory  Common  Application  Directory  Profile 

6.6.1.1  Standard  Application  Specific  Attributes  and  Attribute  Sets 

The  attributes  and  attribute  sets  in  the  Directory  Document,  Part  6,  associated  with  the 
object  classes  listed  below  are  required. 

6.6.1.2  Standard  Application  Specific  Object  Classes 

DSAs  shall  be  able  to  support  storage  and  use  of  the  object  classes  below,  as  defined  in  the 
Directory  Documents,  Part  7,  and  these  object  classes  are  expected  to  be  useful  for  a  range 
of  applications. 

The  following  object  classes  are  mandated  by  the  standard: 

-  Top 

-  DSA 

-  Alias 


6 


Part  11  -  Directory  Services  Protocols  September  1991  (Stable) 

The  following  object  classes  are  expected  to  be  generally  useful  in  the  creation  of  the  DIT  upper  portion: 

a)  Country 

b)  Locality 

c)  Application  Process 

d)  Organization 

e)  Organizational  Unit 

The  following  object  classes  are  expected  to  be  generally  useful  in  the  creation  of  DIT  leaf  entries: 

a)  Alias 

b)  ApplicationProcess 

c)  ApplicationEntity 

d)  DBA 

e)  Device 

f)  Group  of  Names 

g)  OrganizationalPerson 

h)  OrganizationalRole 

i)  ResidentialPerson 

6.6.2       OIW  Directory  Strong  Authentication  Directory  Profile 

6.6.2.1  Other  Profiles  Supported 

This  profile  is  used  in  conjunction  with  the  OIW  Directory  Common  Application  Directory  Profile. 

6.6.2.2  Standard  Application  Specific  Object  Classes 

The  following  object  classes  are  expected  to  be  generally  useful  for  applications  to  support  strong 
authentication: 

a)  Strong  Authentication  User 

b)  Certification  Authority 
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6.7       Restrictions  on  Object  Class  Definitions 

An  object  class  may  not  be  defined  as  a  subclass  of  itself,  as  thte  chain  of  superclasses  of  such  an  object 
class  would  be  a  closed  loop,  isolated  from  all  other  object  classes,  specifically  Top.  Such  isolation  is  clearly 
illegal. 


7      Pragmatic  Constraints 

This  clause  describes  pragmatic  constraints  to  which  a  conformant  implementation  shall  adhere  In  addition 
to  those  specified  in  the  Directory  Documents.  The  pragmatic  constraints  can  be  divided  into  two  major 
areas.  The  first  includes  those  aspects  of  pragmatic  constraints  which  apply  to  scope  of  service  (see  7.1  and 
7.2).  The  second  includes  those  aspects  of  pragmatic  constraints  which  are  specific  to  particular  attribute 
types  (see  7.3). 


7.1       General  Constraints 


7.1.1       Character  Sets 

It  is  a  requirement  to  support  all  character  sets  and  other  name  forms  defined  in  the  Directory  Documents, 
Part  6.  Those  character  sets  include: 

a)  T.61 

b)  PrintableString 

c)  NumericString 


7.1 .2       APDU  Size  Considerations  DSP  BesuR  APDU  Size 

In  the  process  of  chaining  requests  it  is  possible  that  a  ciiaining  DSA  may  receive,  invoke  or  return  APDUs 
that  exceed  its  capacity.  It  is  a  minimum  requirement  tiiat  invoke  APDUs  and  return  result  APDUs  shall  be 
accepted  unless  they  exceed  32767  W^Ml  octets  in  size;in  this  case  they  may  be  discarded  and  an 
"unwillingToPerform"  error  reporting  service  shall  be  used. 

Editor's  Note  -  The  above  change  in  DSP  result  APDU  size  is  to  align  with  other  regional  implementors'  agreements. 
Rgure  4  (APDU  Exchange)  has  been  dropped  in  conjunction  with  the  alignment  change. 
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Figure  5  -  Logical  DSA  Application  Environment. 


7.1.3  Service  Control  (SC)  Considerations 

This  agreement  recognizes  that  DUAs  may  automatically  supply  defaults  for  any  SC  pa- 
rameter. The  choice  of  default  values  selected  (if  any)  is  seen  to  be  a  matter  of  local  policy 
and  consumer  needs. 

7.1.4  Priority  Service  Control 

Priority  is  specified  as  a  service  control  argument  in  the  Directory  Documents.  The  fol- 
lowing statements  represent  a  clarification  of  the  semantics  that  may  be  used  by  a  DSA  in 
interpreting  and  operating  on  this  parameter. 

The  logical  model  in  figure  5  (  page  9)  may  be  considered  as  an  example  by  DSAs  that 
implement  this  Service  Control.  In  figure  5,  note  that: 

-  the  DSA  maintains  three  logical  queues  corresponding  to  the  three  priority  levels; 

-  the  DSA  Scheduler  is  separate  and  distinct  from  any  scheduling  function  provided  by 
the  underlying  operating  system  or  control  program  services; 

-  the  DSA  Scheduler  presents  jobs  to  the  Underlying  Operating  Services  for  execution 
and  always  presents  jobs  of  a  higher  priority  before  those  of  a  lower  priority; 

-  the  DSA  Scheduler  will  not  preempt  a  request  once  it  has  been  passed  to  the  underlying 
operating  system  service. 

7.2     Constraints  on  Operations 

There  are  no  overall  constraints  upon  service  arguments  or  results  except  those  implied 
in  7.1.2  of  this  document. 
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7.2.1  Filters 

It  is  required  that  DSAs,  at  a  minimum,  support  8  nested  "Filter"  parameters,  and  a  total 
limit  of  32  Filter  Items.  If  these  limits  are  exceeded,  the  recipient  of  that  SearchArgument 
may  return  the  ServiceProblem  "unwillingToPerform". 

7.2.2  Errors 

There  are  no  constraints  upon  any  Error  service  except  the  APDU  size  limit  as  defined 
in  7.1.2. 

7.2.3  Error  Reporting  —  Detection  of  Search  Loop 

A  search  operation  may  encounter  a  looping  situation  when  the  search  encompasses  "whole- 
subtree",  and  an  alias  is  encountered  which  is  a  superior  to  some  other  subtree  that  has 
been  encountered  during  the  search. 

DSAs  should  be  able  to  detect  this  situation.  One  possible  method  is  by: 

1.  Maintaining  a  list  of  the  base  objects  of  searches  initiated  as  a  consequence  of  Step  5 
of  Part  4,  clause  18.7.2.2.1  of  the  Directory  Documents  (this  may  require  an  analysis 
of  the  Tracelnformation  field). 

2.  Determining  whether  a  new  base  object  is  superior  to  any  base  object  on  this  list. 

A  new  base  object  which  would  cause  a  loop  in  this  way  should  be  discarded  (i.e.,  should 
not  cause  a  new  search),  but  no  error  should  be  reported  by  an  error-reporting  service.  The 
circumstances  should  be  logged  so  that  it  may  be  reported  to  an  appropriate  Administrative 
Authority  for  rectification. 

7.3     Constraints  Relevant  to  Specific  Attribute  Types 

Table  1  (  pages  40  and  41)  gives  pragmatic  constraints  associated  with  selected  attribute 
types  specified  in  the  Directory  Documents;  many  of  these  constraints  also  appear  and  are 
the  same  in  the  CCITT  version  of  the  Directory  Documents.  Each  constraint  in  table  1  is 
given  in  terms  of  a  length  constraint.  The  length  constraint  for  a  given  attribute  value  is 
the  number  of  units  which  a  sending  entity  shall  not  exceed  and  which  a  receiving  entity 
shall  accept  and  process.  A  sending  entity  need  not  be  capable  of  sending  attribute  values 
as  large  as  the  length  constraints. 

Note  that  in  table  1  the  length  constraint  for  strings  is  expressed  as  the  number  of  allowable 
characters. 

In  addition  to  the  constraints  given  in  table  1,  the  following  constraints  apply  to  alphabets 
and  integer  values. 

-  Alphabets:  T.61  Strings  used  as  attribute  values  shall  only  encode  graphic  characters 
and  spaces.  They  shall  not  contain  formatting  characters  (such  as  subscript)  or  other 
control  characters. 
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-  Integer  Values:  DSAs  shall  be  required  to  "pass  through"  encoded  integer  attribute 
values  of  arbitrary  length  (e.g.,  when  chaining  a  Directory  operation).  No  Directory 
component  (i.e.,  DUA  or  DSA)  shall  be  deemed  non-conformant  if  it  encodes  integer 
attribute  values  of  arbitrary  length. 

Components  of  the  Directory  are  required  to  support  (for  storage  and  processing),  as 
a  minimum,  integer  attribute  values  encoded  in  4  octets. 

8  Conformance 

The  following  subclauses  will  describe  various  aspects  of  Directory  conformance.  It  should 
be  noted  that  conformance  to  the  various  ASEs  and  conformance  to  the  Authentication 
Framework  are  viewed  as  separate  issues  and  are  presented  in  that  context. 

8.1  DUA  Conformance 

Conformance  requirements  for  DUAs  are  adequately  specified  in  the  Directory  Documents, 
Part  5,  clause  9.1  and  the  Directory  Access  Profile  (see  8.6).  It  should  be  noted  that  the 
DUA  conformance  is  based  on  DAP  Protocol  and  not  the  User  Interface.  Not  all  options 
available  in  the  standard  need  to  be  made  available  to  the  user  of  the  DUA. 

It  is  recognized  that  DUAs  will  be  widely  differing  in  nature: 

-  Some  are  intended  to  support  human  users,  some  application  users. 

-  Particular  DUAs  may  not  support  particular  operations  because  the  application  that 
they  support  has  no  requirement;  others  will  be  general  purpose,  and  will  support  all 
operations. 

-  Some  DUAs  will  have  a  fixed  view  of  the  Directory  content  and  structure,  reflecting 
the  usage  of  The  Directory  by  a  particular  application;  others  will  have  a  more  flexible 
view  which  can  be  adapted  to  new  usages. 

-  Some  DUAs  will  provide  automatic  referral  services  with  automatic  establishment  and 
release  of  associations;  others  will  place  the  burden  on  the  user. 

-  Some  DUAs  will  provide  a  variety  of  authentication  means;  others  will  support  no 
authentication 

-  Some  DUAs  will  handle  operations  synchronously;  others  will  have  the  capability  of 
maintaining  several  identifiable  dialogues  with  The  Directory  at  one  time. 

In  the  next  subclause,  different  types  of  DSAs  are  discussed.  The  DUA  is  independent  of 
the  type  of  DSA  it  is  communicating  with  and  does  not  need  to  know  what  type  of  DSA  it 
is  communicating  with. 

8.2  DSA  Conformance 

Basic  conformance  requirements  for  a  DSA  are  defined  in  the  Directory  Documents,  Part  5, 
clause  9.2.  Some  of  the  terms  used  to  describe  DSA  conformance  are  summarized  below. 
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-  Centralized:  A  centralized  DSA  is  defined  as  one  that  contains  its  entire  relevant  DIT; 
it  follows  that  it  will  not  make  use  of  the  DSP  or  generate  referral  responses.  Since 
this  model  only  contains  a  single  DSA  it  is  not  subject  to  DSA  interworking  issues 
and  will  always  provide  a  consistent  level  of  service  and  results.  A  centralized  DSA 
shall  be  fully  "protocol"  conformant  to  the  DAP. 

-  Cooperating:  In  a  distributed  directory,  responsibility  for  various  portions  of  the  DIT 
may  be  "distributed"  among  multiple  DSAs.  On  a  per  operation  basis  we  define  a 
DSA  to  be  holding  when  it  is  responsible  for  the  fragment  of  the  DIB  in  which  a  given 
entry  will  appear  if  it  exists;  we  define  a  DSA  to  be  propagating  when  it  is  unable  to 
complete  the  name  resolution  process. 

All  DSAs  shall  be  capable  of  acting  as  a  holder  and  a  propagator. 

8.3  DSA  Conformance  Classes 

A  DSA  implementation  shall  satisfy  the  conformance  requirements  as  defined  in  the  Di- 
rectory Documents,  Part  5,  subclause  9.2,  and  shall  support  the  "Versions"  argument  of 
"Bind". 

Per  the  conformance  clause  of  the  Directory  Documents,  a  DSA  shall  conform  to  the  abstract 
syntax  of  the  attribute  types  for  which  conformance  is  claimed.  These  attribute  types  shall 
include  those  required  by  6.3  of  this  Implementor's  Agreement. 

Additionally,  an  implementation  conformant  to  these  agreements  shall  state  which  of  the 
following  conformance  classes  it  implements: 

-  Conformance  Class  0  —  Centralized  DSA 

A  DSA  conformant  to  this  class  only  supports  the  DirectoryAccessAC. 

As  the  performance  of  Search  and  List  operations  can  consume  significant  resources, 
the  policies  of  some  centralized  DSAs  may  be  such  that  these  operations  will  not 
be  performed.  For  these  cases,  the  reply  to  requests  for  such  operations  would  be  a 
ServiceError  with  the  "unwillingToPerform"  ServiceProblem. 

-  Conformance  Class  1  -  Distributed  DSA 

A  DSA  implementation  conformant  to  this  class  shall  implement  all  the  operations  in 
the  ASEs  that  are  part  of  the  Application  context  for  which  it  claims  conformance.  It 
shall  support  the  DirectoryAccessAC  and  it  may  optionally  support  the  DirectorySys- 
temAC. 

DSAs  conformant  to  these  Agreements  shall  support  the  OIW  Directory  Common  Appli- 
cation Directory  Profile.  In  addition,  DSAs  may  optionally  conform  to  the  OIW  Directory 
Strong  Authentication  Directory  Profile.  Future  versions  of  these  Agreements  may  allow 
additional  possibilities  for  minimal  profile  conformance. 

8.4  Authentication  Conformance 

A  Directory  System  may  choose  to  implement  various  levels  of  authentication  (Directory 
Documents,  Part  8).  We  define  the  following  levels  of  authentication  in  the  DS: 
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-  No  authentication  at  all;  (None) 

-  Simple  Uncorroborated:  identification  without  verification 

-  Simple  Uncorroborated  authentication  with  verification:   verified  identification 
without  a  password. 

-  Simple  Corroborated  authentication:  verified  identification  with  a  password;  in- 
tended to  make  masquerading  difficult. 

-  Strong  authentication:  identification  with  verification  using  cryptographic  techniques 
intended  to  make  masquerading,  in  practical  terms,  nearly  impossible. 

The  "Authentication  Framework"  document  describes  the  specific  goal  of  each  authentica- 
tion level;  listed  below  are  several  practical  uses  of  the  various  levels.  ^ 

Simple  Uncorroborated  authentication  may  be  desired  to  maintain  access 
statistics  or  in  a  private  network  where  the  initiator  is  implicitly  trusted  and  there 
is  no  need  to  incur  the  additional  overhead  of  more  sophisticated  authentication 
methods. 

Simple  Corroborated  authentication  may  be  necessary  in  situations  where 
strong  authentication  is  not  practical,  (i.e.,  international  connection,  no  knowl- 
edge of  algorithms  in  use,  etc). 

Strong  authentication  will  be  required  for  secure  environments. 

A  DSA  that  implements  Simple  Corroborated  authentication  will  check  the  user  password 
by  means  of  a  compare  operation  on  the  user's  entry.  If  no  user  password  is  supplied  (Simple 
Uncorroborated  authentication)  the  DSA  will  validate  the  presence  of  the  entry  for  the  user, 
by  a  read  operation  or  otherwise.  The  authentication  will  fail  if  the  password  is  incorrect 
or  if  the  user's  entry  does  not  exist. 

A  DSA  that  implements  Simple  Uncorroborated  authentication  without  verification  will 
accept  simple  credentials  without  validating  them. 

Implementations  claiming  conformance  shall,  as  a  minimum,  implement  None  and  Simple 
Uncorroborated  authentication  without  verification. 

8.5     Directory  Service  Conformance 

The  following  subclauses  will  describe  various  aspects  of  Directory  conformance.  Confor- 
mance to  the  Authentication  Framework  is  viewed  as  a  separate  issue  from  conformance  to 
the  rest  of  the  Directory  document  and  is  presented  in  that  context. 

Directory  Profiles  are  broken  into  two  subclauses.  Service  support  specifies  the  level  of 
support  for  operations  and  errors.  Protocol  support  specifies  the  protocol  elements  required 
for  implementations  which  claim  conformance  to  specified  operations. 

To  specify  the  support  for  operations  and  errors,  two  classifications  are  used  as  follows. 

^It  is  the  case  that  some  DSAs  containing  public  information  may  not  require  authentication. 
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1.  r:  required 

The  operation  shall  be  implemented  and  the  respective  error  shall  be  handled  for 
conformance  to  these  agreements. 

For  DUAs,  required  means: 

-  For  ARGUMENT  parameters,  create  the  DAP  protocol  elements  to  convey  the 
service  request  to  the  DSA. 

-  For  RESULT  and  ERROR  parameters,  accept  the  DAP  protocol  elements. 
For  DSAs,  required  means: 

-  For  ARGUMENT  parameters,  accept  the  protocol  elements  when  received  and 
create  the  protocol  elements  when  acting  as  a  requesting  DSA. 

-  For  RESULT  and  ERROR  parameters,  be  able  to  convey  all  possible  results 
w     when  responding  in  either  the  DAP  or  DSP  protocols  and  when  receiving  results, 

perform  additional  processing  as  defined  for  cooperating  DSAs. 

2.  n:  not  required 

It  is  left  to  implementations  as  to  whether  the  operation  or  error  is  implemented  or 
not. 

To  specify  the  support  for  protocol  elements,  four  classifications  are  used  as  follows. 

1.  M:  mandatory 

Generation  of  element  is  a  mandatory  static  conformance  requirement  (i.e.,  a  confor- 
'     mant  implementation  shall  be  capable  of  generating  the  element). 

■     Generation  of  element  is  a  mandatory  dynamic  conformance  requirement  (i.e.,  the 
element  shall  be  present  in  all  instances  of  communication  which  use  the  element). 

The  terms  static  conformance  and  dynamic  conformance  are  defined  in  ISO  9646-1, 
"OSI  Conformance  Testing  Methodology  and  Framework,  Part  1:  General  Concepts." 

2.  G:  generate 

Generation  of  element  is  a  mandatory  static  conformance  requirement. 

Generation  of  element  is  a  conditional  dynamic  conformance  requirement;  the  condi- 
tion is: 

Where  a  DSA  is  a  propagating  DSA,  it  shall  be  capable  of  generating  the 
protocol  element  as  received  in  related  APDUs  received  from  other  DSAs. 
,  ,  Where  the  DSA  is  a  holding  DSA,  it  shall  be  capable  of  creating  all  possible 

values  of  a  protocol  element  unless  otherwise  noted  in  the  "Comments"  line. 

3.  S:  support 

When  receiving  protocol  elements,  implementations  of  these  agreements  shall  be  ca^ 
pable  of  accepting  these  elements  without  error.  Actions  specified  in  the  Directory 
documents  and  in  these  agreements  shall  be  taken. 

4.  O:  optional 

When  generating  protocol  elements: 
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-  Generation  of  element  is  an  optional  static  conformance  requirement.  If  the 
implementor  claims  support  for  the  corresponding  Directory  capability,  then  the 
implementation  shall  be  capable  of  generating  the  element. 

-  Generation  of  element  is  an  optional  dynamic  conformance  requirement.  If  the 
implementor  claims  support  for  the  corresponding  Directory  capability,  then  the 
element  shall  be  present  in  instances  of  communication  which  use  the  element 
(except  where  defaults  allow  otherwise). 

When  receiving  protocol  elements,  implementations  of  these  agreements  shall  be  capa- 
ble of  accepting  these  elements  without  error.  However,  actions  specified  in  the  beise 
standard  and  in  these  agreements  may  be  taken  but  are  not  required. 

Where  protocol  elements  are  nested,  the  classification  of  the  nested  protocol  elements  is 
of  relevance  only  when  the  immediately  containing  protocol  element  is  generated.  The 
classification  of  the  protocol  elements  at  the  highest  level  is  relative  with  respect  to  support 
of  the  operation. 

Also  note  that  in  table  3,  some  rows  contain  two  support  classifications  in  the  DSA  column. 
In  such  cases,  the  support  classification  in  parentheses  applies  to  centralized  DSA's  only. 
When  there  is  only  one  support  classification  given,  it  applies  equally  to  centralized  and 
non-centralized  DSA's. 

8.6  The  Directory  Access  Profile 

This  agreement  requires  implementations  of  the  DUA  to  provide  access  to  the  Directory 
Services  as  defined  in  the  DUA  column  in  table  2.  For  the  services  in  table  2  which  are 
supported,  these  agreements  further  require  DUAs  to  support  the  protocol  elements  as 
defined  in  the  DUA  column  in  table  3  (parts  1-7). 

These  agreements  require  implementations  of  the  DSA  to  support  the  Directory  Services  as 
defined  in  the  DSA  column  in  table  2  (page  42).  These  agreements  further  require  DSAs  to 
support  the  protocol  elements  as  defined  in  the  DSA  column  in  table  3.  Table  3  is  listed  in 
seven  parts  (page  43  through  page  49).  Note  that  the  requirements  for  a  centralized  DSA 
and  a  cooperating  DSA  are  different. 

8.7  The  Directory  System  Profile 

These  agreements  require  implementations  of  distributed  DSAs  which  provide  DSP  to  sup- 
port the  responder  role  for  services  as  defined  in  table  4  (page  50).  Further,  these  agreements 
require  DSAs  to  support  the  protocol  elements  as  specified  in  table  5.  Table  5  is  listed  in 
nine  parts  (page  51  through  page  59). 

DSAs  are  required  to  support  the  requestor  role  for  all  the  services  as  defined  in  table  4  if 
conforming  to  the  chained  mode  of  interaction. 

8.8  Digital  Signature  Protocol  Conformance  Profile 

Table  6  on  page  60  and  table  7  on  page  60  provide  information  on  the  digital  signature 
protocol  conformance  profile. 
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Note  that  elements  in  CommonArguments  and  CommonResults  SecurityParameters  that  are 
not  specified  in  table  6  and  table  7  are  covered  in  the  Directory  Service  Protocol  Support 
(table  5)  and  Directory  Access  Protocol  Support  (table  3). 

8.9     Strong  Authentication  Protocol  Conformance  Profile 

Table  8  on  page  61  and  table  9  on  page  62  provide  information  on  the  strong  authentication 
protocol  conformance  profile. 

9  Distributed  Operations 

The  following  requirements  apply  to  DSAs  supporting  distributed  operations: 

-  DSAs  supporting  authentication  (e.g.,  simple  authentication  by  name  and  password) 
shall  be  able  to  invoke  DSP  operations  to  carry  out  authentication  by  reference  to 
other  DSAs.  Thus  all  such  DSAs  shall  support  the  DSP  protocol.  The  requirement  is 
implied  by  the  Directory  Documents. 

9.1  Referrals  and  Chaining 

It  is  recommended  that  a  DSA  which  has  chained  a  request  act  upon  any  referrals  it  receives 
rather  than  returning  them  to  the  requestor  if  the  "preferChaining"  service  control  is  present. 

9.2  Trace  Information 

A  Tracelnformation  value  carries  forward  a  record  of  the  DSAs  which  have  been  involved  in 
the  performance  of  an  operation.  It  is  used  to  detect  the  existence  of,  or  avoid,  loops  which 
might  arise  from  inconsistent  knowledge  or  from  the  presence  of  alias  loops  in  the  DIT. 

Each  DSA  which  is  propagating  an  operation  to  another,  adds  a  new  item  to  the  trace 
information.  If  the  propagation  of  a  Search  operation  involves  the  creation  of  a  new  Search 
(cf  Directory  Documents,  Part  4,  clause  18.7.2.2.2),  the  trace  information  shall  not  be  re- 
set, but  the  full  trace  information  for  the  overall  Search  operation  to  the  point  where  the 
new  Search  was  generated  shall  be  included  in  the  new  Search. 

10  Underlying  Services 

This  section  specifies  requirements  over  and  above  those  given  in  the  Directory  Documents. 
10.1  ROSE 

It  should  be  noted  that  support  of  "abandon"  implies  support  of  operation  class  2. 
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10.2  Session 

All  directory  implementations  are  required  to  support  Session  Version  2. 

10.3  ACSE 

The  A-ABORT  service  is  required  by  association-accepting  DSAs  to  escape  unwanted  associ- 
ations, which,  under  the  ROSE  protocol,  they  cannot  release.  In  all  other  cases  (association- 
initiating  DSAs  and  DUAs)  it  may  be  preferable  (though  not  required)  to  escape  associations 
using  UNBIND  rather  than  abort. 

The  aborting  DUA  or  DSA  may  optionally  use  the  user  information  field  of  the  A-ABORT. 
Such  information,  however,  is  only  meaningful  for  diagnostic  purposes  and  its  use  is  not 
covered  by  these  Agreements. 

11  Access  Control 

Guidelines  relating  to  access  control  can  be  found  in  Annex  F  of  the  Directory  Documents, 
Part  2. 

12  Test  Considerations 

This  clause  outlines  some  items  that  implementors  may  wish  to  consider  in  terms  of  testing 
expectations;  additionally,  future  conformance  testers  may  wish  to  consider  these  items 
when  developing  tests. 

12.1     Major  Elements  of  Architecture 

One  important  aspect  of  testing  is  to  confirm  the  correct  behavior  of  DSAs  and  DUAs  with 
respect  to  major  elements  of  the  directory  architecture. 

Such  major  elements  include: 

a)  Conformance  Statement 

b)  Distinguished  names  (e.g.,  name  resolution,  equivalence  of  various  forms) 

c)  Entries  and  Attributes  (e.g.,  accessibility  by  operations,  compliance  with  rules) 

d)  Handling  of  distributed  operations  (e.g.,  naming  contexts  and  knowledge) 

e)  Schemas 

1)  Structure  rules  (e.g.,  storage  and  maintenance  of  structure  and  of  naming  rules) 

2)  Object  classes  and  sub-classes  (e.g.,  storage  and  extension  of  rules  for  object 
attributes) 

3)  Attribute  types  (e.g.,  storage  and  maintenance  of  syntax  classes  and  rules  for 
multi  or  single  valued  attributes) 
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4)  Attribute  syntax  (e.g.,  maintenance  and  support  for  attribute  value  testing  and 
matching,  to  specification  for  a  defined  set  of  attribute  types) 

f)  Operations 

1)  all  operations 

2)  correct  function 

3)  correct  result 

4)  correct  responses 

g)  Aliases  (e.g.,  correct  resolution,  error  responses) 

h)  Authentication  and  Access  Control  (e.g.,  limitation  of  modify  access) 

i)  ROSE  (e.g.,  correct  handling  of  invokes,  results,  rejects,  and  invoke  ids) 

j)  ACSE  (e.g.,  association  establishment  /  refusal  for  invalid  application  contexts,  etc.) 

12.2     Search  Operation 

Testing  of  support  for  filter  items  should  be  reasonable.  It  is  not  expected  that  DBAs  will 
be  able  to  handle  worst  case  testing  in  this  area. 

13  Errors 

This  clause  provides  clarification  of  the  semantics  of  various  operation  errors  and  implemen- 
tation guidelines  on  their  usage. 

13.1     Permanent  vs.  Temporary  Service  Errors 

This  subclause  provides  some  clarification  regarding  the  usage  of  the  Service  Errors  busy, 
unavailable,  and  unwillingToPerform. 

The  error  busy  is  particularly  transient.  It  is  returned  when  one  or  more  of  The  Directory's 
internal  resources  are  being  used  to  their  capacity  and,  hence,  the  requested  operation 
cannot,  for  the  moment,  be  performed.  The  Directory  should  be  able  to  recover  from  this 
type  of  resource  depletion  after  a  short  while. 

The  error  unavailable  is  also  temporary  but  somewhat  less  transient.  It  indicates  that  The 
Directory  (or  some  part  of  it)  is  currently  unavailable  and  may  continue  to  be  unavailable 
for  a  reasonably  long  period  of  time.  For  example,  this  error  is  returned  when  a  given  DSA 
is  functionally  disabled,  or  when  a  specific  part  of  the  DIB  is  undergoing  reconfiguration. 

The  error  unwillingToPerform  has  a  permanent  connotation.  It  indicates  that  The  Direc- 
tory cannot  perform  the  requested  operation  because  it  would  require  resources  beyond  its 
capacity.  For  example,  this  error  may  be  returned  by  a  DSA  if  satisfying  a  request  would 
result  in  the  generation  of  an  APDU  in  excess  of  32767  octets. 


18 


PART  11  -  DIRECTORY  SERVICES  PROTOCOLS    December  1990  (Stable) 


13.2     Guidelines  for  Error  Handling 

13.2.1  Introduction 

This  subclause  provides  a  recommended  mapping  of  error  situations  which  may  be  encoun- 
tered to  ROSE  Rejects  or  to  the  errors  provided  in  the  DAP  and  DSP  protocols  of  the 
Directory  Documents. 

The  Directory  Documents  are  not  adequately  definitive  about  the  handling  of  errors.  In 
this  document,  more  explicit  guidelines  are  given. 

Error  situations  are  defined  by: 

-  Symptom  (i.e.,  the  manner  in  which  the  error  was  detected). 

-  Situation  (i.e.,  the  circumstance  or  phase  during  which  the  error  was  detected.  For 
each  possible  situation,  the  error-handling  procedure  needs  to  be  defined). 

13.2.2  Symptoms 

Table  10  (page  63  to  page  65)  describes  a  set  of  symptoms;  the  set  is  not  necessarily  ex- 
haustive. Each  is  identified  by  a  title  which  is  used  later  in  describing  error  actions.  The 
title  used  for  each  symptom  is  not  intended  to  imply  any  particular  usage  in  a  particular 
implementation. 

13.2.3  Situations 

Table  11  (page  66)  identifies  recognized  situations  within  which  particular  symptoms  may 
give  rise  to  distinct  error  actions. 

13.2.4  Error  Actions 

Table  13  (page  68  to  page  73)  summarizes  specific  error  actions  for  each  possible  combination 
of  symptom  and  situation.  Symptoms  are  described  in  13.2.2  and  situations  are  described 
in  13.2.3. 

Each  entry  in  table  13  corresponds  to  the  symptom  in  the  left-most  column  and  the  situation 
given  in  the  column  header.  Each  entry  may  specify: 

-  a  specific  error  action.   The  error  action  is  described  using  the  notation  shown  in 
table  12. 

-  a  specific  error  action  and  a  relevant  note.  The  note  will  be  indicated  by  a  number 
enclosed  in  parentheses.  The  notes  can  be  found  on  page  74. 

-  only  a  relevant  note. 

-  a  blank  (which  indicates  the  corresponding  combination  of  symptom  and  situation  is 
not  meaningful  in  the  context  of  these  Agreements). 

The  entries  in  table  13  which  specify  a  specific  error  action  will  do  so  using  the  notation 
shown  in  table  12  (page  67). 
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13.2.5  Reporting 

In  addition  to  the  use  of  error-reporting  services,  DSAs  should  implement  logging  services 
to  assist  in  management  of  the  Directory.  The  list  below  describes  classes  of  error  which 
should  be  logged.  Note  that  the  list  is  not  necessarily  complete. 

1.  Errors  indicating  attempted  breaches  of  security. 

2.  Errors  indicating  local  software  or  hardware  malfunction. 

3.  Errors  indicating  malfunction  or  other  unacceptable  behavior  on  the  part  of  the  invoker 
of  an  operation. 

4.  Errors  indicating  loss  of  chaining  service  by  another  DSA. 

5.  Error  conditions  that  would  be  difficult  to  diagnose  with  the  level  of  detail  supplied 
over  the  protocol. 

6.  Aborts  and  other  exceptional  communications  events. 
The  form  and  accessibility  of  any  such  logs  is  for  further  study. 

14    Specific  Authentication  Schemes 

This  clause  describes  identified  authentication  algorithms.  Use  of  algorithms  in  this  clause 
is  not  mandatory.  Use  of  algorithms  other  than  those  described  in  this  clause  or  described 
in  the  Directory  Documents  is  by  bilateral  agreement. 

14.1     Specific  Strong  Authentication  Schemes 

This  subclause  provides  information  on  one  alternative  to  the  RSA  digital  signature  scheme. 
The  alternative  is  identified  as  the  "ElGamal"  digital  signature  scheme.  Future  contributions 
may  result  in  other  alternatives  being  added  to  this  subclause. 

Implementors  may  choose  to  provide  digital  signature  capability  based  on  RSA,  ElGamal, 
or  some  other  scheme  appropriate  for  use  in  the  OSI  Directory  environment. 

It  should  be  noted  that  use  of  RSA  is  governed  by  U.S.  patent  law. 
14.1.1  ElGamal 

The  information  in  this  subclause  includes  a  tutorial  description  of  the  ElGamal  scheme 
for  digital  signature  using  the  notation  defined  in  the  Directory  Documents,  Part  8.  It  is 
intended  that  much  of  the  tutorial  information  provided  in  this  subclause  will  be  moved  to 
the  security  agreements  sometime  in  the  future. 

14.1.1.1  Background 

The  ElGamal  digital  signature  scheme  is  based  on  earlier  work  done  by  Diffie  and  Hellman 
[DIFF76]  in  which  it  was  suggested  that  a  likely  candidate  for  a  one-way  function  is  the 
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discrete  exponeniial  function 

f{x)  =  a'=    (modp)  (1) 

where  x  is  an  integer  between  1  and  p—  1  inclusive,  where  p  is  a  very  large  prime  number,  and 
where  a  is  an  integer  such  that  I  <a  <p  and  {a  mod  p,  mod  p,  •  •  • ,  a?"  ^  mod  p}  is  equal 
to  the  set  {1,  2,  •  •  •  ,p  —  1}.  In  algebraic  terminology,  such  an  a  is  called  a  primitive  element 
References  on  the  topic  of  primitive  roots  and  elements  are  [McC179]  and  [PATT87]. 

Now,  in  the  real  number  system,  if  y  =  a^,  then  by  definition  of  the  logarithm  we  can  solve 
for  X  using  X  —  log|^(j/).  The  same  idea  extends  to  solving  eq  (1)  for  x  so  that  inverting  f{x) 
requires  calculating  discrete  logarithms.  The  reason  Diffie  and  Hellman  suspected  eq  (1)  is 
one-way  is  that  for  suitable  p,  it  is  computationally  difficult  to  invert  f{x).  According  to 
the  current  state  of  the  art,  computing  discrete  logs  for  suitable  p  has  been  found  to  require 
a  number  of  operations  roughly  equivalent  to 

exp(\/c61n  b)  (2) 

where  b  is  the  number  of  bits  in  p,  and  c  is  estimated  at  c  =  .69  according  to  [ODLY].  This 
can  be  compared  to  only  about  2  logj  p  multiplications  for  discrete  exponentiation.  If  in  fact 
the  best  known  algorithm  for  computing  discrete  logs  is  near  optimal  then  Expression  (2) 
is  a  good  measure  of  the  problem's  complexity  (for  a  properly  chosen  p)  and  the  discrete 
exponential  function  has  all  the  qualities  of  a  one-way  function  as  described  by  Difhe  and 
Hellman. 

14.1.1.2     Digital  Signature 

•  Private  Key:  Xs  denotes  the  private  key  for  user  X.  Xg  is  a  randomly  chosen  integer 
which  user  X  keeps  secret. 

•  Public  Key  :  Xp  denotes  the  public  key  for  user  X  and  is  calculated  using  the  corre- 
sponding private  key  such  that 

Xp  =  ct^s    (mod  p)  (3) 

where 

—  p  is  a  prime  satisfying  the  requirements  listed  in  14.1.1.4. 

—  a  is  a  primitive  element  mod  p. 

—  Note  that  p  and  a  could  be  used  globally,  but  because  they  should  be  easily 
changeable  (see  14.1.1.4  for  information  about  why  these  two  parameters  should 
be  easily  changeable)  it  would  probably  be  preferable  for  each  user  to  choose 
his/her  own  p  and  a.  If  users  choose  their  own,  then  p  and  a  must  be  made 
available  to  the  recipient  for  use  in  the  signature  verification  process. 

•  Signing  Procedure:  Suppose  user  A  wants  to  sign  a  message  intended  for  recipient  B. 
The  basic  idea  is  to  compute  a  two  part  signature  (r,  s)  for  the  message  m  such  that 

a^{rn)  ^  ^ApYr'    (mod  p)  (4) 

where  /i  is  a  one-way  hash  function. 
Compute  the  signature  (r,  s)  as  follows. 
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1.  Choose  a  random  number  k,  uniformly  between  0  and  p  —  1  such  that  k  and  p—l 
have  no  common  divisor  except  1  (i.e.,  gcd(fc,p—  1)  =  1). 

2.  Compute  r  such  that 

r  =  a''    (mod  p)  (5) 

3.  Use  r  to  solve  for  the  corresponding  s  as  follows. 

(a)  rewrite  eq  (4)  using  eq  (5)  and  the  definition  of  the  public  key  to  get 

Combining  exponents,  get 

^him)  -  ^(As)r+ks    (rnodp)  (7) 

eq  (7)  implies  that 

,   ;    :  h{m)  =  {As)r  +  ks    (modp-1)  (8) 

Note  that  eq  (8)  has  a  single  solution  for  s  because  k  was  chosen  such  that 
gcd(fc,p—  1)  =  1.  See  [SIER88]  for  supporting  theorem. 

(b)  now  solve  for  s  and  get 

s  =  I{h{m)  -  (As)r)    (modp-1)  (9) 

where  /  is  computed  such  that  k  *  I  =  1    (mod  p—l). 
The  ElGamal  signature  is  comparable  in  size  to  the  corresponding  RSA  signature. 

14.1.1.3  Verification 

The  recipient  receives  Ap,m,r,s,a,  and  p  and  computes  both  sides  of  eq  (4)  and  then 
compares  the  results. 

14.1.1.4  Known  Constraints  on  Parameters 

The  following  list  of  constraints  is  the  result  of  a  search  of  current  literature  and  may  not 
be  complete. 

1.  p  must  be  prime 

2.  p  must  be  large. 

Note  that  Expression  (2)  can  be  used  to  speculate  on  the  level  of  security  afforded  by 
cryptosystems  based  on  the  discrete  log  problem.  Breaking  the  ElGamal  scheme  has 
not  been  proven  to  be  equivalent  to  finding  discrete  logs,  but  if  we  assume  equivalence 
then  we  can  estimate  how  large  p  should  be  for  a  desired  level  of  security. 

For  instance,  suppose  we  wanted  to  use  Expression  (2)  to  decide  how  large  p  should 
be  so  that  we  can  be  reasonably  sure  the  system  cannot  be  broken  (using  the  best 
known  algorithm)  in  a  practical  amount  of  time.  To  be  on  the  conservative  side,  we 
decide  we  want  to  protect  against  a  special  purpose  machine  that  can  perform  10-^^ 


22 


PART  11  -  DIRECTORY  SERVICES  PROTOCOLS    December  1990  (Stable) 


operations  per  second.  Specifically,  we  want  to  know  how  large  p  should  be  so  that 
such  a  machine  would  take  at  least  one  year  to  break  the  system. 

In  one  year,  the  hypothetical  machine  can  perform  3  x  10^^  operations.  To  find  the 
size  of  the  desired  p,  solve  the  following  equation  for  b. 

exp(\/cMn6)  =  3  X  10^2  (10) 

We  get  h  1^  606.  This  is  the  number  of  bits  in  the  desired  p.  So,  the  magnitude  of  the 
desired  p  is  about  2^°^  which  is  roughly  266  x  10^^°. 

Hence,  to  be  reasonably  sure  of  attaining  the  desired  level  of  security,  we  find  a  prime 
number  greater  than  266  x  10^*°  which  satisfies  all  the  other  criteria  listed  in  this 
subclause.  Our  confidence,  however,  is  strictly  based  on  the  assumption  that  breaking 
ElGamal  is  as  difficult  as  finding  discrete  logs  and  the  assumption  that  the  best  known 
algorithm  for  finding  discrete  logs  is  near  optimal. 

3.  p  should  occasionally  be  changed.  This  requirement  is  discussed  in  [ODLY84]  and  is 
related  to  the  discovery  of  new  algorithms  for  computing  discrete  logarithms  in  GF{p). 

4.  p  —  1  must  have  at  least  one  large  prime  factor.  This  requirement  is  discussed  in 
[ODLY84]  and  is  imposed  by  the  Silverman-Pohlig-Hellman  algorithm  which  com- 
putes discrete  logarithms  in  GF(p)  using  on  the  order  ^/r  operations  and  a  comparable 
amount  of  storage,  where  r  is  the  largest  prime  factor  in  p  —  1. 

5.  p  should  not  be  the  square  of  any  prime.  A  subexponential-time  algorithm  for  com- 
puting discrete  logarithms  in  GF{j?)  has  been  found.  See  [ELGA85b]  for  details. 

14.1.1.5     Note  on  subjectPublicKey 

The  ASN.l  data  element  subjectPublicKey,  defined  as  BIT  STRING  in  Annex  (G)  of 
Directory  Documents,  Part  8,  should  be  interpreted  in  the  case  of  ElGamal  as  being  of  type: 

SEqUENCE{  INTEGER,  INTEGER  } 

where  the  first  integer  is  the  Arithmetic  Modulus  and  the  second  is  the  primitive  element 
for  the  finite  field.  The  sequence  is  represented  by  the  ASN.l  Basic  Encoding  Rules. 

Implementors  should  take  note  that  the  size  of  the  integers  used  for  these  parameters  is 
expected  to  exceed  the  pragmatic  constraints  specified  for  integers  by  the  upper  layers  SIG. 

14.1.2     One- Way  Hash  Functions 
14.1.2.1    SQUARE-MOD-N  Algorithm 

Recent  research  regarding  the  square-mod-n  one-way  hash  function  described  in  Annex  D 
of  the  Directory  Documents,  Part  8,  has  revealed  that  the  function  is  not  secure.  Its  use, 
therefore,  is  discouraged. 
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14.1.2.2  MD2  Algorithm 

MD2  is  a  one-way  hash  function  and  is  described  in  [RFC1115].  Implementors  should  note 
that  the  use  of  MD2  may  be  subject  to  license  agreements. 

14.1.2.3  Study  of  Other  One- Way  Hash  Functions 

The  Directory  SIG  is  studying  the  applicability  of  alternative  one-way  hash  functions.  One 
recent  development  in  this  area  was  the  announcement  by  Ralph  Merkle  that  2-pass  SNE- 
FRU is  broken;  its  use  is  therefore  discouraged.  Refer  to  the  Working  Agreements  for  further 
status  on  the  study  of  one-way  hash  functions. 

14.1.2.4  Use  of  One— Way  Hash  Functions  in  Forming  Signatures 

MD2  may  be  used  to  form  digital  signatures  in  conjunction  with  RSA  or  ElGamal. 

14.1.3     ASN.l  for  Strong  Authentication  Algorithms 

This  subclause  defines  object  identifiers  assigned  to  authentication  algorithms.  The  defini- 
tions take  the  form  of  the  ASN.l  module,  "OIWAlgorithmObjectldentifiers". 

OIWAlgorithmObject Identifiers  {iso(l)  identif ied-organization(3) 

oiw(14)  dssig(7) 

oIWAlgor ithmOb j  ect Ident  if iers ( 1 ) } 

DEFINITIONS  : := 
BEGIN 

EXPORTS 

md2,  md2WithRSA,  elGamal,  md2WithElGamal ; 

IMPORTS 

authenticationFramework 

FROM  Usef ulDef initions  {joint-iso-ccitt  ds(5)  modules(l) 

usef  ulDef  initions(0)]■ 
ALGORITHM  FROM  AuthenticationFramework 

authenticationFrconework; 

—  categories  of  object  identifiers 

algorithm  OBJECT  IDENTIFIER  ::=  {iso(l)  identif ied-organization(3) 

oiw(14)  dssig(7)  algorithm(2)> 

encriptionAlgorithm  OBJECT  IDENTIFIER  ::=  {algorithm  1} 

hashAlgorthm  OBJECT  IDENTIFIER  ::=  {algorithm  2} 
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signature Algorithm  OBJECT  IDENTIFIER    ::=  {algorithm  3} 

—  algorithms 

md2  ALGORITHM 

PARAMETER  NULL 
::=  {hashAlgorithm  l} 

md2WithRsa  ALGORITHM 
PARAMETER  NULL 
::=  {signatureAlgorithm  1} 

elGamal  ALGORITHM 
PARAMETER  NULL 
::=  {encryptionAlgorithm  1} 

Editor's  Note:  Refer  to  the  June  1990  Working  Agreements  for  information  re- 
garding why  PARAMETER  NULL  is  specified  above  for  the  ElGamal  encryption 
algorithm. 

md2WithElGamal  ALGORITHM 
PARAMETER  NULL 
::=  {signatureAlgorithm  2} 

END  —  of  Algorithm  Object  Identifer  Definitions 
14.1.4     Note  on  the  ENCRYPTED  MACRO 

The  value  associated  with  the  ENCRYPTED  MACRO,  as  defined  in  Directory  Documents, 
part  8,  clause  8.4  shall  be  interpreted  in  the  case  of  ElGamal  as  being  type: 

SEQUENCE{  INTEGER,  INTEGER  } 

The  first  integer  in  the  sequence  is  r  (see  eq  (5),  14.1.1.2).  The  second  integer  is  5  (see  eq 
(9),  14.1.1.2). 

14.2     Protected  Simple  Authentication 

Protecting  the  user's  distinguished  name  and  password  provides  greater  degrees  of  security 
than  where  passwords  are  not  protected. 

The  procedure  for  achieving  this  protection,  referred  to  as  protected  simple  authentication, 
is  outlined  in  the  Directory  Documents,  Part  8,  clause  5.3.  The  approach  by  which  protected 
identifying  information  may  be  generated  is  outlined  in  the  Directory  Documents,  Part  8, 
clause  5.4.  For  the  purpose  of  these  agreements,  fl  and  /2  as  specified  in  the  Directory 
Documents,  Part  8,  clause  5.4  are  identical  MD2  one-way  functions.  The  algorithms  for 
implementation  of  the  MD2  one-way  function  are  described  in  [RFC1115]  (see  D.3).  Note 
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that  the  use  of  MD2  may  be  subject  to  licensing  agreement.  Use  of  other  algorithms  for 
other  one-way  functions  is  by  bilateral  agreement. 

User  A  generates  Protected2  as  specified  in  the  Directory  Documents,  Part  8,  clause  5.4. 
Authenticator2  is  then  conveyed  to  B  in  the  form  of  SimpleCredentials.  Table  14  on  page  75 
shows  the  relationship  between  SimpleCredential  fields  and  the  elements  of  protected  simple 
authentication  as  shown  in  figure  2  of  the  Directory  Documents,  Part  8. 

14.3     Simple  Authentication 

There  are  two  major  classes  of  authentication  supported  by  the  Directory  (i.e.,  simple  and 
strong  authentication).  Simple  authentication  is  based  on  a  password  being  passed  between 
the  two  associated  entities  (e.g.,  between  a  Directory  User  and  a  DUA,  or  between  two 
DBAs).  In  the  case  of  interaction  between  a  Directory  User  and  a  DUA,  the  password  is 
compared  in  some  way  with  the  password  attribute  in  the  user's  entry  in  the  Directory.  In 
the  case  of  interaction  between  two  DSAs,  this  cannot  be  done  since  the  DSA  object  class, 
as  defined  in  the  Directory  Documents  (Part  7,  clause  6.14)  does  not  contain  a  password 
attribute. 

To  facilitate  simple  authentication  between  DSAs,  it  is  recommended  that  a  DSA  have  local 
access  to  a  list  of  one  or  more  known  DSAs,  with  a  copy  of  each  known  DSA's  password. 
Maintenance  of  that  information  is  done  through  the  use  of  bilateral  agreements  between 
DSA  administrators. 
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Annex  A 

(normative) 
Maintenance  of  Attribute  Syntaxes 


A.l  Introduction 

The  attribute  types  defined  in  the  Directory  Documents,  Part  6,  and  listed  in  table  1 
(page  40)  have  requirements,  in  DSAs  which  support  them,  for  underlying  algorithms  that: 

-  check  attribute  values  for  syntactical  correctness  and  compliance  with  pragmatic  con- 
straints; 

-  match  attribute  values  (comparing  for  equality,  for  matching  substrings,  and  for  rela- 
tive ordering). 

A. 2     General  Rules 

A  DSA  may  receive  a  legitimately  encoded  attribute  or  AVA  that  is  unsupported  by  the 
DSA.  If  the  DSA  is  not  required  to  act  on  it,  or  to  store  it  within  an  entry,  it  may  handle 
it  by  passing  it  on  without  error.  Such  attributes  may  also  be  used  in  search  filter-item 
definitions:  in  this  case,  no  error  is  reported,  but  the  filter-item  shall  be  deemed  to  be 
undefined  for  all  entries  in  the  DSA.  This  rule  applies  to  occurrences  of  attributes  in  both 
operation  arguments  and  results. 

Conversely,  a  DSA  must  return  a  suitable  error  if  an  operation  requires  it  to  act  on  or  store 
an  attribute  or  AVA  of  type  unsupported  by  the  DSA.  This  constraint  applies  even  for  AVAs 
that  are  contained  in  attributes  that  take  names  as  values,  since  the  DSA  will  be  unable 
correctly  to  match  the  attribute  values  without  this  attribute  information. 

A. 3    Checking  Algorithms 

The  subclauses  below  give  additional  checks  (beyond  those  directly  implied  by  the  Directory 
Documents)  which  shall  be  applied  to  attributes  before  they  are  stored  in  the  DSA. 

A. 3.1  distinguishedNameSyntax 

Each  component  AVA  must  be  checked,  unregistered  attribute  types  comprising  an  error; 
check  also  that  no  two  AVAs  in  the  same  RDN  have  the  same  attribute  type. 

A. 3. 2  integerSyntax 

Local  implementations  may  apply  local  limitations. 
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A. 3. 3  telephoneNumberSyntax 

The  value  of  policing  further  rules  is  for  further  study  (this  applies  also  to  telexNumber,  tele- 
texTerminalldentifier,  facsimileTelephoneNumber,  G3FacsimileNonBasicParameters,  xl21Address, 
and  iSDN Address). 

A. 3. 4  countryName 

The  value  must  be  checked  for  compliance  with  IS03166:  1981  (E/F).  (Note  that  from  time 
to  time  further  codes  may  be  allocated.) 

A. 3. 5     preferredDelivery  Method 

The  values  of  the  integer  elements  should  not  be  restricted. 

A. 3. 6  presentationAddress 
No  further  checks  should  be  applied. 

A. 4    Matching  Algorithms 

Matching  algorithms  are  conveniently  defined  in  terms  of  a  two-step  process: 

1.  Take  the  checked  reference  value,  and  the  value  to  be  matched,  and,  if  necessary, 
reduce  them  to  a  canonical  (i.e.,  standard)  form  (normalization)  appropriate  to  each 
attribute  syntax. 

2.  Carry  out  the  comparison  in  the  specified  way  (e.g.,  equality,  substrings  or  ordering) 
using  the  appropriate  rules  for  the  value  -  character  string,  integer,  boolean,  etc. 

Note  that  the  lexical  ordering  of  character  strings  (when  supported)  may  be  subject  to  local 
rules. 

IMPORTANT  NOTE:  The  combination  of  normalization  and  comparison  may  be  re- 
placed, in  a  particular  implementation,  by  equivalent  procedures.  Additional  notes  on  nor- 
malization are  given  below. 

A.4.1  UTCTimeSyntax 

If  the  "seconds"  field  is  absent,  it  shall  be  inserted,  and  set  to  "00",  and  the  form  converted 
to  the  "Z"  form.  Note.  The  normalization  strategy  does  not  match  times  where  the  stored 
form  omits  the  seconds  field,  and  the  compared  form  contains  it,  e.g., 

8804261919Z 

880426191926Z 
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(It  might  have  been  expected  that  these  two  forms,  which  coincide  in  time  to  within  a  few 
seconds,  would  be  considered  identical.) 

A. 4. 2  distinguishedNameSyntax 

For  each  attribute  value,  carry  out  normalization  in  accordance  with  the  normalization  rules 
defined  for  the  type  (if  registered);  values  corresponding  to  unregistered  attribute  types  are 
left  unchanged  at  this  stage. 

A. 4. 3  caselgnoreListSyntax 

To  facilitate  matching,  particularly  for  substrings,  normalization  may  be  considered  in  terms 
of  a  representation  which  replaces  the  separate  ASN.l  elements  by  a  single  string  with  a 
delimiter. 
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Annex  B 

(informative) 
Glossary 

The  following  abbreviations  may  be  useful;  not  all  are  used  within  these  agreements. 


JV  Ij 

Access  Control  List 

Association  Control  Service  Element 

A  LJ 1)  iVl  U 

Administration  Directory  Management  Domain 

ArLi  i  itle 

Application  ilintity  iitle 

A  Ty  in  T  T 

Application  rrotocol  Data  Unit 

A  CTT 

Application  Service  Element 

A  CM  1 

Abstract  Syntax  Notation  -  1 

AAA  A 

Attribute  Value  Assertion 

Jj  rCiVl 

Basic  Reference  Model 

C  A 

Certification  Authority 

ine  International  ielegrapn  and  ielepnone  Consultative  Committee 

Committee  for  European  Normalization 

Committee  for  European  Normalization  Electronique 

(Committee  of  European  Posts  and  Telephones) 

Corporation  for  Open  Systems 

T\  A  !  ) 

Directory  Access  Protocol 

JJIJ3 

Directory  Information  Base 

TilT 

Directory  Information  Tree 

U  JVIU 

Directory  Management  Domains 

T~»  C  A 

Ua  A 

Directory  System  Agent 

Directory  System  Protocol 

FllTT  A 

Directory  User  Agent 

European  Workshop  for  Open  Systems 

File  Transfer,  Access  &  Management 

ilN  1 AP 

T    i.                      L'l'x       rn      1_*1A             '     J.'          r        T    ^               i.*T>                 '  T 

interoperability  iechnical  Association  lor  Information  Processing,  Japan 

TO  T\  XT 

Integrated  Services  Digital  Network 

International  Organization  tor  Standardization 

Ty 

K  1 

Knowledge  iree 

T  T 

JLLi 

Lower  layers  of  OSI  model  (layers  1-4) 

■\/T  A  T* 

Manufacturing  Automation  Protocol 

MHS 

Message  Handling  Systems 

NIST 

National  Institute  of  Standards  and  Technology 

NSAP 

Network  Services  Access  Point 

OSI 

Open  Systems  Interconnection 

PKCS 

Public  Key  Crypto  System 

POSI 

Promotion  for  Open  System  Interconnection 

PRDMD 

Private  Directory  Management  Domain 

PSAP 

Presentation  Service  Access  Point 

RDN 

Relative  Distinguished  Name 

ROSE 

Remote  Operations  Service  Element 

SSAP 

Session  Service  Access  Point 

SIG 

Special  Interest  Group 

SPAG 

Standards  Promotion  &  Application  Group 
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TOP  Technical  and  Office  Protocols 

TSAP  Transport  Service  Access  Point 

UL  Upper  layers  of  OSI  model  (layers  5-7) 

UPU  Universal  Postal  Union 
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Annex  C 
(informative) 
Requirements  for  Distributed  Operations 

The  following  material  is  included  for  tutorial  purposes,  and  does  not  represent  material 
additional  to  the  Directory  Documents.  It  is  also  not  intended  as  a  complete  statement 
of  requirements  (the  Distributed  Operations  part  of  the  Directory  Documents  should  be 
referred  to  for  a  complete  treatment). 

C.l     General  Requirements 

DSAs  supporting  distributed  operations  and  claiming  support  of  chaining  must  fully  support 
DSP,  as  defined  by  the  Directory  Documents.  DSAs  supporting  distributed  operations  must 
always  be  able  to  accept  incoming  DSP  associations  and  invocations.  DSAs  claiming  support 
of  chaining  must  support: 

-  Loop  detection 

-  Loop  avoidance 

In  passing  on  operations  (when  chaining  or  multi-casting),  the  original  DAP-supplied  in- 
vocation must  be  passed  on  without  change  of  content.  In  particular,  there  must  be  no 
alteration  in  any  way  of  any  primitive  content. 

The  support  of  a  facility  for  returning  cross-references  (Directory  Documents,  Part  4,  clause 
10.4.1)  is  optional. 

To  ensure  that  tracelnformation  can  be  analyzed  properly,  DSAs  shall  only  possess  names 
that  are  compliant  with  the  recommendations  of  the  Directory  Documents,  Part  7  (including 
Annex  B). 

C.2     Protocol  Support 

C.2.1     Usage  of  ChainingArguments 

When  using  ChainingArguments:  ^ 

-  originator  need  not  be  used  if  requestor  in  CommonArguments  is  used; 

-  targetObject  shall  not  be  used  unless  the  target  object  differs  from  object/base  object 
(if  it  is  present,  object/base  object  are  ignored  for  purposes  of  name  resolution); 

-  operationProgress,  tracelnformation,  aliasDereferenced,  aliasedRDNs,  referenceType, 
and  timeLimit  shall  be  generated,  accepted,  and  used  in  accordance  with  the  Directory 
Documents; 

-  returnCrossReferences  and  info  may  optionally  be  generated,  and  shall  always  be  ac- 
cepted. 

^In  this  subclause,  the  names  of  protocol  elements  (within  ChainingArguments)  are  italicized. 
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C.2.2     Usage  of  ChainingResults 

When  using  ChainingResults:  ^  crossReferences  and  info  may  optionally  be  generated,  and 
shall  always  be  accepted. 


^In  this  subclause,  the  names  of  protocol  elements  (within  ChainingResults)  are  italicized. 
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Annex  D 

(informative) 

Guidelines  for  Applications  Using  the  Directory 


D.l  Tutorial 
D.1.1  Overview 

Applications  may  have  a  requirement  for  Directory  functionality.  This  tutorial  provides 
assistance  to  those  groups  intending  to  specify  Directory  usage  for  a  specific  application 
(e.g.,  Message  Handling  Systems). 

D.l. 2     Use  of  the  Directory  Schema 
D.l. 2.1     Use  of  Existing  Object  Classes 

Applications  wishing  to  use  the  Directory  should  have  determined  within  a  standard,  Im- 
plementor's  Agreements,  or  on  a  propriety  basis,  the  relevant  Directory  schema  for  their 
objects.  Consider  the  following  two  examples: 

1.  Network  management  applications  may  with  to  define  a  SMAE  object  class. 

2.  File  transfer  applications  may  with  to  define  a  File  Store  object  class. 

Groups  should  examine  relevant  standards  to  determine  if  application-specific  object  classes 
or  attributes  have  been  already  defined  before  considering  any  additional  definition.  These 
object  classes  and  attributes  may  be  found  in  a  variety  of  places  including  a  specific  appli- 
cation standard  (e.g.,  [Recommendation  CCITT  '88  X.402  |  ISO  10021-2]  and  the  Directory 
Documents).  Standardized  object  classes  and  attributes  should  be  strongly  considered  be- 
fore additional  schema  elements  are  created. 

D.1.2.2     Kinds  of  Object  Classes 

There  are  effectively  two  kinds  of  object  classes  permitted  within  the  Directory  Documents: 
structural  and  auxiliary.  The  terms  structural  and  auxiliary  are  used  here  for  convenience 
when  referring  to  particular  kinds  of  object  classes.  The  terms  themselves  are  not  defined 
in  the  Directory  Documents. 

Structural  object  classes  have  associated  DIT  structure  rules  (which  control  naming).  En- 
tries of  this  object  class  type  are  intended  to  be  instantiated  in  Directory  entries.  A  struc- 
tural object  class  provides  information  on  the  base  mandatory  and  optional  content  of  a 
DIT  entry. 

An  auxiliary  object  class  provides  information  to  enhance  the  mandatory  and  optional 
contents  of  entries.  It  is  always  used  in  conjunction  with  a  structural  object  class. 
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The  object  class  hierarchy  is  formed  as  a  result  of  the  definition  of  structural  object  classes, 
and  the  addition  of  auxiliary  object  classes. 

For  example,  all  object  classes  in  the  Directory  Documents,  Part  7,  are  structural  except 
for  strongAuthentication  User  and  certificationAuthority.  These  two  object  classes  should 
be  considered  auxiliary  and  used  in  conjunction  with  other,  structural  object  classes. 

D.1.2.3     Use  of  Unregistered  Object  Classes 

The  Directory  Documents,  Part  2,  clause  9.4.1  provides  a  "special"  form  of  object  class 
called  "unregistered."  An  unregistered  object  class  is  not  assigned  an  object  identifier. 
One  of  the  uses  for  unregistered  object  classes  is  to  provide  a  means  of  creating  a  single 
Directory  entry  which  logically  represents  a  variety  of  object  classes.  Uses  for  unregistered 
object  classes  include: 

-  Locally  adding  attributes  to  a  predefined  superclass; 

-  Locally  making  optional  attribute  types  in  a  predefined  superclass  mandatory; 

-  Creating  an  object  class  derived  from  multiple  superclasses,  without  needless  prolifer- 
ation of  registered  object  classes. 

For  example,  it  may  be  advantageous  to  provide  an  entry  which  represents  a  person  who  is 
both  a  MHS  and  a  FTAM  user. 

Unregistered  object  classes  may  best  be  illustrated  by  example.  Consider  an  entry  which 
represents  a  collection  of  company  entries  for  Fizzy  Company  whose  users  have  MHS  0/R 
addresses.  Using  the  guidelines  above,  the  Fizzy  Company  defines  an  unregistered  object 
class  using  the  structural  object  class  organizationalPerson  from  the  Directory  Documents, 
Part  7,  and  the  auxiliary  object  class  mhs-user  from  the  MHS  standards  [Recommendation 
X.402  I  ISO  10021-2]  as  follows: 

f izzyCompanyPerson  ::=  OBJECT-CLASS 
SUBCLASS  OF  organizationalPerson,  mhs-user 
MUST  CONTAIN  {} 
MAY  CONTAIN  {} 


Note  that  no  object  identifier  is  assigned. 

Also  note  that  since  there  are  not  MUST  or  MAY  CONTAIN's  in  the  fizzyCompanyPerson 
Object  Class,  the  last  two  lines  of  the  object  class  assignment  (i.e.,  "MUST  CONTAIN  MAY 
CONTAIN  ")  are  optional.  As  with  the  registered  form  of  object  classes,  an  unregistered  ob- 
ject class  always  inherits  all  the  attributes  in  any  of  its  superclasses.  There  is  no  mechanism 
defined  whereby  a  subclass  may  selectively  inherit  attributes  from  its  superclasses. 

An  unregistered  object  class  always  appears  as  a  leaf  in  the  Object  Class  tree  (i.e.,  an 
unregistered  object  class  may  not  be  a  superclass  of  some  other  object  class). 

Using  unregistered  object  classes  in  conjunction  with  multiple  inheritance  is  useful  as  shown 
by  figure  6  in  which  three  ways  of  creating  the  same  two  object  classes  are  shown.  Either 
three,  four,  or  five  registered  object  classes  are  used. 
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per  mhs  ae 

\  /      \  / 

mhs-per[ur]  mhs-ae[ur] 

Example  a 

[ur]        =  unregistered 
per         =  person 
mhs  =  mhs-user 

ae  =  applicationEntity 

Figure  6  -  Three  Ways  of  Creating  Two  Object  Classes. 

Examples  (a)  and  (c)  in  figure  6  are  both  better  ways  of  defining  the  object  classes  than 
that  in  example  (b),  even  though  example  (c)  needs  to  use  one  more  registered  object  class 
than  example  (b).  This  is  because  the  multiple  inheritance  technique,  used  in  examples  (a) 
and  (c),  enables  a  Directory  User  searching  the  Directory  to  easily  create  a  filter  to  find  all 
entries  that  contain  mhs-user  attributes,  based  on  a  value  in  the  object  class  attribute  (Each 
Directory  entry  contains  a  list  of  the  object  identifiers  of  the  object  classes  it  has  inherited 
from,  so  the  filter  would  just  have  to  find  all  entries  that  held  the  object  identifier  value  of 
mhs-user). 

Example  (a),  which  uses  three  registered  object  classes,  is  better  than  example  (c),  which 
uses  five,  because  registering  the  extra  two  object  classes  does  not  provide  any  advantage 
over  not  registering  them,  and  the  first  method  avoids  needless  proliferation  of  registered 
object  classes. 


per             ae        I  per         mhs  ae 

I                I           I  \        /      \  / 

mhs-per    mhs-ae      I  mhs-per  mhs-ae 
I 

Example  b  Excunple  c 


D.1.2.4     Side  Effects  of  Creating  Unregistered  Object  Classes 

This  subclause  discusses  two  side  eff'ects  of  creating  unregistered  object  classes. 

1.  When  an  unregistered  object  class  is  defined  from  a  single  superclass,  there  is  no 
means  available  to  distinguish  between  the  two.  Within  the  local  scope  for  which 
the  unregistered  class  is  defined,  all  relevant  entries  are  considered  to  belong  to  the 
unregistered  class. 

The  following  is  an  example  of  this  problem: 

An  object  class  of  oCl(reg)  has  attribute  type  atl  mandatory  and  at2  op- 
tional. An  unregistered  form  of  this,  oCl(unreg)  is  created,  which  makes  at2 
mandatory.  When  an  Add  Entry  operation  is  received  with  both  attributes 
present,  the  entry  could  belong  to  either  form  of  oCl;  it  is  indeterminate. 
After  the  entry  is  added  a  Modify  Entry  operation  is  received  which  requests 
the  removal  of  attribute  type  at2.  It  is  not  clear  if  this  operation  should 
succeed,  or  whether  an  object  class  violation  should  be  reported.  If  the 
attribute  may  be  removed,  then  the  entry  belonged  to  the  oCl(reg)  object 
class  and  the  unregistered  form  never  existed,  otherwise  if  the  attribute  may 
not  be  removed,  then  the  entry  belonged  to  oCl(unreg)  and  the  registered 
form  no  longer  exists. 
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2.  More  than  one  unregistered  object  class  cannot  be  defined  from  the  same  superclass(es) 
for  use  within  the  same  local  scope,  as  there  is  no  means  available  to  distinguish  the 
classes  from  one  another. 

D.2     Creation  of  New  Object  Classes 

If  no  appropriate  object  class  is  available,  a  new  object  class  may  be  defined.  This  should 
only  be  done  if  no  standardized  object  classes  and  attributes  can  fulfill  the  requirements. 

D.2.1     Creation  of  New  Subclasses 

Generally,  an  application-specific  object  class  is  defined  as  a  subclass  of  a  pre-existing  Di- 
rectory object  class.  These  object  classes  are  specified  in  the  Directory  Documents,  Part  7. 
The  subclass  may  be  structural  or  auxiliary.  Optional  attributes  of  the  superclass  may  be 
made  mandatory.  New  attributes  may  also  be  added. 

For  example,  MHS  has  used  the  Directory  structural  object  class  applicationEntity  to  derive 
the  object  class  for  their  MHS-specific  application  entity  MTAs. 

If  absolutely  no  relevant  object  class  is  available,  an  object  class  maybe  defined  as  a  subclass 
of  the  basic  object  class  called  "Top". 

If  no  appropriate  object  class  is  available,  a  new  object  class  may  be  defined.  This  should 
only  be  undertaken  if  no  standardized  object  class  can  fulfill  the  requirements.  When 
defining  new  object  classes  the  object-class  macro,  as  defined  in  the  Directory  Documents, 
Part  2,  clause  9.4.6,  should  be  used. 

If  new  subclasses  are  defined,  suggested  or  required  name  forms  may  also  be  specified  in 
text. 

D.2. 2     Creation  of  New  Attributes 

If  no  appropriate  attributes  are  available,  a  new  attribute  type  may  be  defined.  This  should 
only  be  undertaken  if  no  standardized  attributes  can  fulfill  the  requirements.  ¥/hen  defining 
new  attributes  the  attribute  macro,  as  defined  in  the  Directory  Documents,  Part  2,  clause 
9.5.3,  should  be  used. 

D.3    DIT  Structure  Rules 

Applications  may  desire  to  provide  guidance  on  DIT  structure  rules  and  naming.  As  with 
object  classes,  standardized  or  suggested  structure  (including  naming)  rules  from  the  Di- 
rectory Documents  part  7,  Annex  B  and  application-specific  standards  should  be  consulted 
before  providing  new  structure  rules.  Annex  B  in  the  Directory  Documents,  Part  7,  provides 
guidelines  on  how  to  specify  this  information.  Structure  rules  associated  with  superclasses 
should  be  adopted  wherever  suitable. 
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Annex  E 

(informative) 

Template  for  an  Application  Specific  Profile  for  Use  of 

the  Directory 

The  template  defined  below  should  be  used  by  OIW  SIGs  intending  to  specify  Directory 
usage.  Such  application  specific  profiles  shall  be  contained  in  application  specific  chapters 
of  the  OIW  agreements.  The  information  under  each  heading  should  be  filled  in  (the  text 
under  each  heading  provides  guidance  on  the  meaning  of  the  heading  and  should  not  be 
included  in  the  profile). 

-  PROFILE  TITLE 

Application  specific  profiles  are  named  in  the  following  way: 

OIW  <SIG-NAME>  <DESCRIPTOR>  DIRECTORY  PROFILE 
(e.g.,  OIW  DIRECTORY  STRONG  AUTHENTICATION  DIRECTORY  PROFILE  ) 

-  OTHER  PROFILES  SUPPORTED 

other  OIW  Directory  profiles  which  are  to  be  used  by  this  specific  application  are  listed 
here.  Attributes,  attribute  sets,  object  classes  and  structure  rules  that  are  referenced 
in  these  profiles  need  not  be  enumerated  below. 

-  STANDARD  APPLICATION  SPECIFIC  ATTRIBUTES  AND  ATTRIBUTE  SETS 

Any  attributes  supported  from  the  relevant  standards.  For  example,  the  MHS  SIG 
might  include  mhs-or-address  here. 

-  STANDARD  APPLICATION  SPECIFIC  OBJECT  CLASSES 

Any  object  classes  supported  from  the  relevant  standards.  For  example,  the  MHS  SIG 
might  include  mhs-user  here. 

-  OIW  APPLICATION  SPECIFIC  ATTRIBUTES  AND  ATTRIBUTE  SETS 

This,  optional,  component  of  this  profile  allows  for  the  specification  of  OIW  application 
specific  attributes  and  attribute  sets.  This  section  of  this  template  should  be  used 
rarely  and  with  consideration  that  no  standard  profile  or  attribute/attribute  set  exists 
which  can  be  used. 

-  OIW  APPLICATION  SPECIFIC  OBJECT  CLASSES 

This,  optional,  component  of  this  profile  allows  for  the  specification  of  OIW  application 
specific  object  classes.  This  section  of  this  template  should  be  used  rarely  and  with 
consideration  that  no  standard  profile  or  object  class  exists  which  can  be  used. 

-  STRUCTURE  RULES 

Guidance  for  DIT  structural  rules,  provided  only  when  structure  rules  associated  with 
superclasses  are  not  adopted.  The  Directory  Documents,  Part  7,  Annex  B  provide  an 
example  and  guideline  to  use  in  specifying  this  information. 
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Table  1  -  Pragmatic  Constraints  for  Selected  Attributes  (Part  1  of  2) 


Attribute  Type 

Content 

Constraints 

Primary 
Source 

Notes 

Aliased  Object  Name 

Distinguished 
Name 

Note  3  (page  41) 

Business  Category 

T.61    or  Printable 
String 

ub-business-category 
128 

CCITT 
X.520 

Common  Name 

T.61    or  Printable 
String 

ub-common-name 
64 

CCITT 
X.520 

Country  Name 

Printable  String 

2 

ISO 
3166 

Description 

T.61    or  Printable 
String 

ub-description 
1024 

CCITT 
X.520 

About  1  screen  full 

Destination  Indicator 

Printable  String 

ub-destination-indicator 
128 

CCITT 
X.520 

Facsimile  Telephone 
Number 

Facsimile  Telephone 
Number 

ub-telephone-number 
32 

CCITT 
X.520 

Optionally  includes  03 
non-basic  parameters 
(Upper  bounds  ffs) 

International  ISDN 
Number 

Numeric  String 

ub-isdn-address 
lb 

CCITT 
A.OZU 

E.164  Internat'l  ISDN 
Number 

Knowledge  Informa- 
t  ion 

T.61   or  Printable 

^'^  n  n  cr 

1024 

OIW 

About  1  screen  full 

Locality  Name 

T.61    or  Printable 
otrmg 

ub-locality-name 

1  o  o 

izo 

CCITT 

Member 

Distinguished 
Name 

Note  3  (page  41) 

Object  Class 

Object  Identifier 

256  octets 

OIW 

Organization  Name 

T.61    or  Printable 
String 

ub-organization-name 
64 

CCITT 
X.520 

Organizational  Unit 
Name 

1.61    or  rrmtable 
String 

ub-organizational-unit- 
name  64 

CCITT 
X.520 

Owner 

Distinguished 
Name 

Note  3  (page  41) 

Physical  Delivery 
Office  Name 

l.bl    or  Prmtable 
String 

ub-physical-omce-name 
128 

CCITT 
X.520 

Post  Office  Box 

T.61    or  Printable 
String 

ub-post-office-box 
40 

CCITT 
X.520 

Postal  Address 

Postal  Address 

ub-postal-line  6 
ub-postal-string  30 

CCITT 
X.520 

UPU 

Postal  Code 

T.61    or  Printable 
String 

ub-postal-code 
40 

CCITT 
X.520 

Presentation  Address 

Presentation 
Address 

224  octets 

NIST 

Note  2  (page  41),  ISO 
7498.3  &  X.200 
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Table  1  -  Pragmatic  Constraints  for  Selected  Attributes  (Part  2  of  2) 


Attribute  Type 

Content 

Constraints 

Primary 

k—J      Li  1. 

Notes 

Registered  Address 

Postal  Address 

ub-postal-line  6 
ub-postal-string  30 

CCITT 
X.520 

Role  Occupant 

Distinguished 
Name 

Note  3  (page  41) 

Search  Guide 

Guide 

256 

OIW 

See  Also 

Distinguished 
Name 

Note  3  (page  41) 

Serial  Number 

Printable  String 

ub-serial-number 
64 

CCITT 
X.520 

State     or  Province 
Name 

T.61    or  Printable 
String 

ub-state-name 
128 

CCITT 
X.520 

Street  Address 

T.61    or  Printable 
String 

ub-street-address 
128 

CCITT 
X.520 

Supported 

Application  Context 

Object  Identifier 

256 

OIW 

Surname 

T.61    or  Printable 
String 

ub-surname 
64 

CCITT 
X.520 

Telephone  Number 

Printable  String 

ub-telephone-number 
32 

CCITT 
X.520 

E.123 

Teletex  Terminal 
Identifier 

Teletex  Terminal 
Identifier 

ub-teletex-terminal-id 
1024 

CCITT 
X.520 

Optionally  includes 
Telstex  non-basic  pa- 
rameters (upper  bound 
ffs) 

Telex  Number 

Telex  Number 

ub-telex-number  14 
ub-country-code  4 
ub-answerback  8 

CCITT 
X.520 

Contains    sequence  of 
telex  number,  country 
code,  and  answerback 

Title 

T.61    or  Printable 
String 

ub-title 
64 

CCITT 
X.520 

User  Password 

Octet  String 

ub-user-password 
128 

CCITT 
X.520 

Allow   long  passwords 
generated  by  machine 

X.121  Address 

Numeric  String 

ub-xl21-address 
15 

CCITT 
X.520 

X.121 

Notes  for  table  1 

1.  The  pragmatic  constraints  of  these  parameters  are  defined  in  other  standards.  We 
will  accommodate  these  values  in  our  pragmatic  constraints. 

2.  Presentation  address  is  composed  of  "X"  NSAP  addresses,  and  three  selectors, 
(20^"  +  32  +  16  +  16),  e.g.,  i{  X  =  1,  this  would  be  84.  These  numbers  are  based 
on  the  most  recent  implementors'  agreements.  With  8  NSAP  addresses  this  value  is 
224. 

3.  Pragmatic  constraints  are  only  applied  to  the  individual  components  of  Distinguished- 
Name  as  defined  in  the  Directory  Documents,  Part  2.  Not  aU  components  of  a  DN  will 
necessarily  be  understood  by  an  implementation. 

4.  Implementors  should  be  aware  that  constraints  on  Postal  Address  may  not  be  suffi- 
cient for  some  markets. 
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Table  2  -  Directory  Access  Service  Support. 


Support 
Classification 

(.r»Tn  m  f^n  f  c 

DUA 

DSA 

-  BIND  and  UNBIND  - 

DirectoryBind 

r 

r 

L-'ircci*jiy  uiiuixiu. 

r 

r 

-  OPERATIONS  - 

Read 

n 

r 

v_/oiiipa.re 

n 

r 

n 

r  (note  2) 

-  SEARCH  OPERATIONS  - 

T  iof 

n 

r  (note  Ij 

Sc3.rcli 

n 

r  (note  1) 

-  MODIFY  OPF,R  ATTONS  - 

A  HHF.ntrv 

n 
11 

1 

XCClliW  V  CXjII  1 1  V 

n 

r 

MoHifvFntrv 

n 

ivi  o  (J  1 1  y  xv  JU'  IN 

n 

r 

-  ERRORS  - 

Abandoned 

(note  4) 

r 

AbandonedFailed 

(note  4) 

r 

AttributeError 

(note  4) 

r 

NameError 

(note  4) 

r 

Referral 

(note  4) 

r  (note  3) 

SecurityError 

(note  4) 

r 

ServiceError 

(note  4) 

r 

UpdateError 

(note  4) 

r 

Notes  for  table  2 

1.  As  performance  of  Search  and  List  operations  can  consume  significant  resources,  the 
policies  of  some  centralized  DSAs  may  be  that  such  operations  wlU  not  be  performed. 
For  these  cases,  the  reply  to  the  requests  for  such  operations  would  be  ServiceError 
with  the  "unwillingToPerform"  Service  Problem. 

2.  Reference  Directory  Documents,  Part3,  clause  9.3.6 

3.  Centralized  DSAs  would  not  generate  referrals. 

4.  See  EntrylnformationSelection  under  Common  Data  Types  (table  3,  Part  6). 
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Table  3  -  DAP  Protocol  Support  (Part  1  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

-  BIND  and  UNBIND  - 

DirectoryBind 

DirectoryBindArgument 

M 

s 

credentials 

O 

s 

simple 

O 

s 

name 

G 

s 

validity 

0 

o 

password 

G 

c 

b 

strong 

(J 

r\ 
U 

See  Strong  Authentication  Protocol  Conformance  Profile  for  re- 

quirements when  strong  authentication  is  supported. 

externalProcedure 

o 

o 

vcroiuiio 

o 

s 

Supported  value:  vl988 

DirectoryBindResult 

s 

G 

credentials 

o 

G 

Shall  be  the  same  CHOICE  as  in  DirectoryBindArgument. 

simple 

0 

G 

name 

s 

G 

validity 

0 

O 

password 

o 

0 

strong 

o 

O 

See  Strong  Authentication  Protocol  Conformance  Profile  for  re- 

quirements when  strong  authentication  is  supported. 

externalProcedure 

o 

0 

versions 

s 

O 

Supported  value:  vl988 

Directory  BindError 

s 

G 

versions 

s 

O 

Supported  value:  vl988 

ServiceProblem 

s 

G 

Supported  value:  unavailable 

SecurityProblem 

s 

G 

Supported  values:  inappropriateAuthentication,  invalidCredentials 

DirectoryUnbind 

The  DirectoryUnbind  has  no  arguments. 
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Table  3  -  DAP  Protocol  Support  (Part  2  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

-  OPERATIONS,  ARGUMENTS  AND  RESULTS  - 

-  READ  OPERATIONS  - 

Read 

ReadArgument 

M 

s 

object 

M 

s 

selection 

O 

s 

See  note  2  on  page  49. 

CommonArguments 

O 

s 

ReadResult 

S 

G 

entry 

S 

M 

CommonResults 

S 

G 

Compare 

CompareArgument 

M 

b 

object 

M 

s 

purported 

M 

S 

CommonArguments 

O 

s 

CompareResult 

s 

G 

DistinguishedName 

s 

G 

matched 

s 

M 

fromEntry 

s 

G 

CommonResults 

s 

G 

Abandon 

AbandonArgument 

M 

s 

invokeld 

M 

s 

AbandonResult 

s 

G 

-  SEARCH  OPERATIONS  - 

List 

ListArgument 

M 

s 

object 

M 

s 

CommonArguments 

O 

s 

ListResult 

S 

G 

listlnfo 

s 

G 

DistinguishedName 

s 

G 

subordinates 

s 

M 

Rel. DistinguishedName 

s 

M 

For  the  case  where  subordinates  is  empty  set,  RDN  is  absent. 

aliasEntry 

s 

G 

fromEntry 

s 

G 

partialOutcomeQualifier 

s 

G 

CommonResults 

s 

G 

UncorrelatedListlnfo 

s 

G(0) 

ListResult 

s 

G 

See  note  1  on  page  49  for  additional  information  related  to  the 

DSA  support  classification. 
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Table  3  -  DAP  Protocol  Support  (Part  3  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

Search 

SearchArgument 

M 

s 

baseObject 

M 

s 

subset 

O 

s 

filter 

o 

s 

searchAliases 

o 

s 

selection 

0 

s 

CommonArguments 

o 

s 

SearchResult 

s 

G 

searchinfo 

s 

G 

DistinguishedName 

s 

G 

entries 

s 

M 

partialOutcomeQualifier 

s 

G 

CommonResults 

s 

G 

uncorrelatedSearchinfo 

s 

G(0) 

SearchResult 

s 

G 

partialOutcomeQualifier 

s 

G 

limit  Problem 

s 

G 

unexplored 

s 

G 

unavailableCriticalExt 

s 

O 

-  MODIFY  OPERATIONS  - 

AddEntry 

AddEntryArgument 

M 

S 

object 

M 

S 

entry 

M 

s 

CommonArgument 

O 

S 

AddEntryResult 

s 

G 

RemoveEntry 

RemoveEntry  Argument 

M 

s 

object 

M 

s 

CommonArguments 

0 

s 

RemoveEntry  Result 

b 

G 

ModifyEntry 

Modify  Entry  Argument 

M 

s 

object 

M 

s 

changes 

M 

s 

At  least  one  entry  modification  must  be  supported. 

addAttribute 

O 

s 

removeAttribute 

O 

s 

addValues 

o 

s 

remove  Values 

o 

s 

CommonArguments 

o 

s 

ModifyEntryResult 

s 

G 
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Table  3  -  DAP  Protocol  Support  (Part  4  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

Modify  RDN 

ModifyRDNArgument 

M 

S 

object 

M 

s 

newRDN 

M 

s 

deleteOldRDN 

O 

s 

O 

G 

ModifyRDNResult 

s 

G 

-  ERRORS  AND  PARAMETERS  - 

Abandoned 

AbandonFailed 

problem 

s 

M 

operation 

s 

M 

AttributeError 

object 

s 

M 

problems 

s 

M 

Min.     1  error  (See  Directory  Documents,   Part  3, 

subclause  12.4.2.2) 

type 

s 

M 

value 

s 

G 

NameError 

problem 

s 

M 

matched 

s 

M 

Referral 

candidate 

s 

G 
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Table  3  -  DAP  Protocol  Support  (Part  5  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

SecurityError 

problem 

S 

M 

ServiceError 

problem 

S 

M 

UpdateError 

problem 

S 

M 

-  COMMON  ARGUMENTS  /  RESULTS  - 

CommonArguments 

ServiceControls 

0 

S 

SecurityParameters 

o 

S 

See  subclause  8.8. 

certification-path 

0 

S 

name 

o 

S 

time 

0 

s 

random 

o 

s 

target 

o 

s 

requestor 

0 

s 

OperationProgress 

o 

S(0) 

nameResolutionPhase 

M 

S 

nextRDNToBeResolved 

o 

s 

aliasedRDNs 

0 

S(0) 

extensions 

o 

S 

iclentmer 

M 

s 

critical 

0 

s 

item 

M 

s 

CommonResults 

SecurityParameters 

0 

G(0) 

See  subclause  8.8. 

certification-path 

o 

G 

name 

0 

G 

time 

o 

G 

random 

o 

G 

target 

0 

G 

performer 

o 

G(0) 

aliasDereferenced 

0 

G 
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Table  3  -  DAP  Protocol  Support  (Part  6  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

-  COMMON  DATA  TYPES  - 

ServiceControls 

options 

O 

s 

priority 

0 

s 

timeLimit 

O 

s 

sizeLimit 

O 

s 

scopeOfReferral 

o 

s 

EntrvInformationSelection 

attributeTypes 

o 

s 

allAttributes 

O 

s 

Must  support  at  least  one  of  the  UJlOlCr/. 

select 

O 

s 

infoTypes 

o 

s 

Entrylnformation 

DistinguishedName 

S 

M 

fromEntry 

S 

G 

SET  OF  CHOICE 

S 

G 

AttributeType 

S 

G 

Attribute 

S 

G 

Filter 

Must  support  at  least  one  of  the  CHOICE. 

item 

o 

S 

and 

o 

S 

or 

o 

s 

not 

o 

s 

Filterltem 

equality 

o 

s 

substrings 

o 

s 

type      .     ^'  ■  .     ' - 

M 

s 

strings 

M 

s 

initial 

0 

s 

Must  support  at  least  one  of  the  CHOICE. 

any 

0 

s 

final 

o 

s 

greaterOrEqual 

0 

s 

lessOrEqual 

0 

s 

present 

0 

s 

approximateMatch 

o 

s 
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Table  3  -  DAP  Protocol  Support  (Part  7  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

SecurityParameters 

O 

0 

See  subclause  8.8. 

certification-path 

O 

S 

name 

O 

S 

time 

O 

S 

random 

O 

S 

target 

0 

S 

ContinuationReference 

0 

M 

aliasedRDNs 

0 

G 

OperationProgress 

0 

M 

nameResolutionPhase 

0 

M 

nextRDNToBeResolved 

O 

G 

rdnsResolved 

0 

G 

AccessPoint 

O 

M 

AccessPoint 

Name 

0 

M 

Presentation  Address 

0 

M 

pSelector 

0 

G 

sSelector 

o 

G 

tSelector 

o 

G 

nAddress 

o 

M 

Notes  for  table  3 

1.  As  performance  of  Search  and  List  operations  can  consume  significant  resources,  the 
policies  of  some  centralized  DBAs  may  be  that  such  operations  will  not  be  performed. 
For  these  cases,  the  reply  to  the  requests  for  such  operations  would  be  ServiceError 
with  the  "unwiUingToPerform"  Service  Problem. 

2.  See  EntrylnformationSelection  information  under  Common  Data  Types  (table  3,  part 
6) 
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Table  4  -  Directory  System  Service  Support. 


Operations  and  Errors 

Support 
Classification 

Comments 

Request 

XLCOL'^^lioC. 

RTND  anrl  TTNRTNn 

—  DiriLJ  anQ  UlNlJliNU  — 

DSABind 

n 

(notes  1,2) 

r 

DSAUnbind 

n 

(notes  1,2) 

r 

-  OPERATIONS  - 

-  CHAINED  READ  OPERATIONS  - 

ChainedRead 

n 

(notes  1,2) 

r 

ChainedCompare 

n 

(notes  1,2) 

r 

n 

(note 

1) 

r 

-  PHATNFD  c;t?aPPH  OPFP  ATTON^:  _ 

Vw*  H  d  1 1 1 C    ±j  1  o  t 

(note 

1) 

1* 

1 

n  o.  1  n  c  u.  o  c  a.  1  c  n. 

n 

(note 

1) 

T 

-  CHAINED  MODIFY  OPERATIONS  - 

XX  S^1.X  1                ITX  \^  1-J  XX    X      V-/  X    X^  X  vjTI.  J.  X       X 1 

C^h^inf^H  AHHEnf  rv 

n 

(note 

1) 

r 

ChainedRemoveEntry 

n 

(note 

1) 

r 

ChainedEntry 

n 

(note 

1) 

r 

ChainedModifyRDN 

n 

(note 

1) 

r 

-  ERRORS  - 

Abandoned 

n 

(note 

1) 

r 

Abandonfailed 

n 

(note 

1) 

r 

AttributeError 

n 

(note 

1) 

r 

NameError 

n 

(note 

1) 

r 

DSARefFeral 

n 

(note 

1) 

r 

SecurityError 

n 

(note 

1) 

r 

SeviceError 

n 

(note 

1) 

r 

UpdateError 

n 

(note 

1) 

r 

Notes  for  table  4 

1.  Necessary  when  supporting  the  chained  mode  of  interaction. 

2.  Some  of  these  operations  may  be  necessary  to  support  distributed  authentication. 
This  requirement  is  distinct  from  support  for  chained  mode  of  interaction. 
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Table  5  -  DSP  Protocol  Support  (Part  1  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  BIND  and  UNBIND  - 

DSABind 

DirectoryBindArgument 

M 

s 

credentials 

G 

s 

simple 

G 

s 

name 

G 

s 

validity 

O 

o 

password 

G 

s 

strong 

O 

o 

Sec  Strong  Authentication  Protocol  Conformance  Profile 

for  requirements  when  strong  authentication  is  supported. 

externalProcedure 

r\ 
\J 

versions 

G 

s 

Supported  value:  vl988 

JJoArJmarCesult 

S 

G 

credentials 

c 

Shall  be  the  same  CHOICE  as  in  DirectoryBindArgument. 

simple 

S 

G 

name 

S 

G 

validity 

o 

0 

password 

S 

G 

strong 

0 

0 

See  Strong  Authentication  Protocol  Conformance  Profile 

for  requirements  when  strong  authentication  is  supported. 

externalProcedure 

0 

0 

versions 

S 

G 

Supported  value:  vl988 

DirectoryBindError 

s 

G 

versions 

s 

G 

Supported  value:  vl988 

ServiceProblem 

s 

G 

Supported  values:  busy  and  unavailable. 

Security  Problem 

s 

G 

Supported  values:  inappropriateAuthentication,  invalid- 

Credentials. 

DSAUnbind 

The  DSAUnbind  has  no  arguments. 

i 
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Table  5  -  DSP  Protocol  Support  (Part  2  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  OPERATIC 

)NS  ARG 

JMENTS  A 

ND  RESULTS  - 

-  CHAINED  READ  OPERATIONS  - 

ChainedRead 

ChainingArgument 

M 

s 

ReadArgument 

M 

s 

object 

M 

s 

selection 

G 

s 

CommonArguments 

G 

s 

ChainingResult 

S 

M 

ReadResult 

S 

M 

entry 

S 

M 

CommonResults  * 

S 

G 

ChainedCompare 

ChainingArgument 

M 

S 

Compare  Argument 

M 

S 

object 

M 

S 

purported 

M 

s 

CommonArguments      ■  ^ 

G 

s 

ChainingResult 

S 

M 

CompareResult 

S 

M 

DistinguishedName 

S 

G 

matched  s 

S 

M 

fromEntry 

S 

G 

CommonResults 

s 

G 

ChainedAbandon 

AbandonArgument 

M 

S 

invokeld 

M 

S 

AbandonResult 

s 

G 
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Table  5  -  DSP  Protocol  Support  (Part  3  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  OPERATIONS,  ARGUMENTS  AND  RESULTS  - 

CnainedList 

ChainingArguments 

M 

b 

ListArgument 

M 

S 

object 

M 

S 

CommonArguments 

G 

s 

ChainingResuIts 

S 

M 

ListResult 

S 

M 

listlnio 

c 

DistinguishedName 

c 
o 

n. 

subordinates 

c 

o 

M 
iVl 

Rel.  DistmguisnedN  ame 

c 

JVi 

T  J. 

aliasEntry 

/~\ 
\J 

iromEntry 

b 

partialOutcomeQualifier 

s 

G 

CommonResults 

s 

G 

uncorrelatedListlnfo 

c 
o 

ex 

T  *    i-T)  li- 

ListKesuit 

c 
b 

/-^ 
\J 

C/nainedSearcn 

Search  Argument 

M 

C 

O 

baseObject 

M 

b 

sugset 

r  \ 

G 

b 

filter 

G 

S 

searchAliases 

G 

S 

selection 

c 
o 

CommonArguments 

/-"I 

(J 

c 
b 

s 

M 

SearchResult 

S 

M 

Searchinfo 

s 

M 

DistinguishedName 

s 

G 

entries 

s 

M 

partialOutcomeQualifier 

s 

G 

CommonResults 

s 

G 

uncorrelatedSearchinfo 

s 

G 

SearchResult 

s 

G 

partialOutcomeQualifier 

s 

G 

limitProblem 

s 

G 

unexplored 

s 

G 

unavailableCriticalExt 

s 

G 
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Table  5  -  DSP  Protocol  Support  (Part  4  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  CHAINED  MODIFY  OPERATIONS  - 

ChainedAddEntry 

ChainingArguments 

M 

S 

AddEntry  Argument 

M 

S 

object 

M 

IVi 

entry 

M 

s 

Common  Arguments 

G 

s 

ChainingResults 

S 

M 

A  HH  En  trvResiilts 

S 

M 

ChainedRemoveEntry 

ChainingArguments  ! 

M 

S 

RemoveEntryArgument 

M 

S 

object  ; 

M 

S 

CommonArguments 

G 

S 

i 

ChainingResults  1 

S 

M 

RemoveEntryResult  \ 

s 

M 

ChainedModify  Entry 

ChainingArguments 

M 

s 

Modify  EntryArgument 

M 

S 

object 

M 

S 

changes 

M 

S 

addAttribute 

G 

S 

removeAttribute 

G 

S 

addValues 

G 

S 

removeValues 

G 

s 

CommonArguments 

Q 

ChainingResults 

S 

M 

Modify  Entry  Result 

S 

M 

ChainedModifyRDN 

ChainingArguments 

M 

s 

ModifyRDNArgument 

M 

s 

object 

M 

S 

newRDN 

M 

s 

deleteOldRDN 

G 

s 

CommonArguments 

G 

S 

ChainingResults 

S 

M 

Modify  RDNResult 

S 

M 
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Table  5  -  DSP  Protocol  Support  (Part  5  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  ERRORS  and  PARAMETERS  - 

Abandoned 

AbandonFailed 

problem 

S 

M 

operation 

S 

M 

AttributeError 

Min.    1  error  (see  Directory  Documents,  part  3, 

subclause  12.4.2.2) 

object 

S 

M 

problems 

S 

M 

problem 

S 

M 

type 

S 

M 

value 

s 

G 

NameError 

problem 

s 

M 

matched 

s 

M 

DSARefferal 

ContinuationReference 

s 

M 

contextPrefix 

s 

G 

SecurityError 

problem 

s 

M 

r 
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Table  5  -  DSP  Protocol  Support  (Part  6  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

ServiceError 

S 

G 

For  Directory  operations 

problem 

S 

M 

UpdateError 

S 

G 

problem 

S 

M 

-  COMMON  ARGUMENTS  /  RESULTS  - 

Common  Arguments 

ServiceControls 

G 

S 

SecurityParameters 

O 

S 

see  subclause  8.8. 

requestor 

G 

s 

OperationProgress 

G 

s 

nameResolutionPhase 

M 

s 

nextRDNToBeResolved 

G 

s 

aliasedRDNs 

G 

s 

extensions 

G 

s 

identifier 

M 

s 

critical 

G 

s 

item 

M 

s 

CommonResults 

SecurityParameters 

S 

O 

See  subclause  8.8. 

requestor 

S 

G 

aliasDereferenced 

S 

G 
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Table  5  -  DSP  Protocol  Support  (Part  7  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  COMMON  DATA  TYPES  - 

ServiceControls 

options 

G 

S 

priority 

G 

S 

timeLimit 

G 

S 

sizeLimit 

G 

s 

scopeOfReferral 

G 

s 

LntrylniormationSeiection 

attributeTypes 

G 

s 

allAttributes 

G 

s 

select 

G 

s 

infoTypes 

G 

s 

bntrylniormation 

DistinguishedName 

S 

M 

from  Entry 

S 

G 

bEi  CHOICE 

S 

G 

Attribute  iype 

S 

G 

AttriDUte 

S 

G 

r  liter 

item 

G 

s 

and 

G 

S 

or 

G 

s 

not 

G 

s 

h  ilterltem 

equality 

G 

s 

substrings 

G 

s 

type 

G 

s 

strings 

G 

s 

initial 

G 

s 

any 

G 

s 

final 

G 

s 

greaterOrEqual 

G 

s 

lessOrEqual 

G 

s 

present 

G 

s 

approximateMatch 

G 

s 
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Table  5  -  DSP  Protocol  Support  (Part  8  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  COMMOI 

^  DATA  T 

YPES  FOR 

DISTRIBUTED  OPERATION  - 

ChainingArguments 

originator 

vjr 

c 

targetObject 

G 

S 

cinf^TPi  t  inn  ProtTrp<^<; 

G 

s 

nameResolutionPhase 

M 

s 

nextRDNToBeResolved 

G 

s 

tracelnformation 

M 

s 

aliasDereferenced 

G 

s 

aliasedRDNs 

G 

s 

returnCrossRefs 

G 

s 

See  Directory  Documents,  Part  4,  subclause  10.4.1 

referenceType 

G 

s 

Domainlnfo 

0 

o 

timeLimit 

G 

s 

SecurityParameters 

0 

s 

See  note  1  (page  59)  regarding  the  support  classifica- 

tion for  Request.  Also  see  subclause  8.8 

ChainingResults 

Info 

0 

0 

crossReferences 

s 

G 

SecurityParameters 

s 

0 

See  note  1  (page  59)  regarding  the  support  classifica- 

tion for  Response.  Also  see  subclause  8.8 

CrossReference 

contextPrefix 

s 

M 

See  Directory  Documents,  Part  4,  subclause  12.4.2.2 

accessPoint 

M 

Tracelnformation 

Traceltem 

M 

s 

Traceltem 

dsa 

M 

S 

targetObject 

G 

S 

operationProgress 

M 

S 

nameResolutionPhase 

M 

s 

nextRDNToBeResolved 

G 

s 
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Table  5  -  DSP  Protocol  Support  (Part  9  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

ContinuationReference 

targetObject 

S 

M 

aliasedRDNs 

S 

G 

operationProgress 

S 

M 

nameResolutionPhase 

S 

M 

next  RD  NToBeResolved 

S 

G 

rdnsResolved 

S 

G 

referenceType 

S 

G 

AccessPoint 

S 

M 

AccessPoint 

Name 

s 

M 

PresentationAddress 

S 

M 

pSelector 

S 

G 

sSelector 

S 

G 

tSelector 

s 

G 

nAddress 

s 

M 

Notes  for  table  5 

1.  The  support  classification  is  G  when  supporting  the  chained  mode  of  interaction. 

2.  Some  of  these  operations  may  be  necessary  to  support  distributed  authentication. 
This  requirement  is  distinct  from  support  for  chained  mode  of  interaction. 
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Table  6  -  DAP  Support  for  Digital  Signature  Protocol  Conformance  Profile. 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

-  COMMON  ARGUMENTS  /  RESULTS  - 

CommonArguments 

SecurityParameters 

certification-path 

G 

S 

name 

G 

S 

time 

G 

S 

random 

G 

S 

target 

G 

S 

requestor 

G 

S 

CommonResults 

SecurityParameters 

S 

G 

performer 

S 

G 

Table  7  -  DSP  Support  for  Digital  Signature  Protocol  Conformance  Profile. 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

-  COMMON  ARGUMENTS  /  RESULTS  - 

CommonArguments 

SecurityParameters 

certification-path 

G 

S 

name 

G 

S 

time 

G 

s 

random 

G 

s 

target 

G 

s 

requestor 

G 

s 

CommonResults 

SecurityParameters 

G 

s 

performer 

O 

G 
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Table  8  -  DAP  Support  for  Strong  Authentication  Protocol  Conformance  Profile. 


Protocol  ililement 

Support 
Classification 

Comments 

DUA 

DSA 

• 

Directory  BindArgument 

M 

S 

credentials 

G 

s 

simple 

G 

s 

name 

G 

s 

validity 

G 

s 

password 

G 

s 

strong 

certification-path 

G 

s 

bind-token 

G 

s 

externalProcedure 

O 

o 

versions 

O 

s 

DirectoryBindResult 

S 

G 

credentials 

S 

G 

simple 

S 

G 

name 

S 

G 

validity 

S 

G 

password 

S 

G 

strong 

S 

G 

certification-path 

s 

G 

bind-token 

S 

G 

externalProcedure 

0 

0 

versions 

S 

O 
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Table  9  -  DSP  Support  for  Strong  Authentication  Protocol  Conformance  Profile. 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

DirectoryBindArgument 

M 

S 

credentials 

G 

s 

simple 

G 

s 

name 

G 

s 

validity 

G 

s 

password 

G 

s 

strong 

certification-path 

G 

s 

bind-token 

G 

s 

externalProcedure 

O 

0 

versions 

0 

s 

DirectoryBindResult 

S 

G 

credentials 

S 

G 

simple 

S 

G 

name 

S 

G 

validity 

S 

G 

password 

S 

G 

strong 

S 

G 

certification-path 

S 

G 

bind-token 

S 

G 

externalProcedure 

0 

O 

versions 

s 

0 
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Table  10  -  Error  Symptoms  (Part  1  of  3) 


Symptom 

Descripton 

EJlCCESS 

The  initiator  has  insufficient  access  rights  to  carry  out  this  operation. 

E_ADMIN_LIMIT 

The  Directory  has  reached  some  limit  set  by  an  administrative  authority, 
and  no  partial  results  are  available  to  return  to  the  user. 

EJ^LIAS_DEREF 

One  of  three  situations  exists: 

1.  An  alias  has  been  encountered  while  a  previous  alias  was  being  deref- 
erenced, or 

2.  a  name  contained  an  alias  plus  one  or  more  additional  RDNs  when 
the  dontDereferenceAliases  service  control  was  being  used,  or 

3.  the  name,  supplied  in  an  operation  that  precludes  alias  dereferencing, 
i^vjxi tdiiicu  dii  diictb  pxuo  one  or  iiiorc  duciitioncii  xxLyiib. 

E-ALIAS-LOOP 

During  a  whole-subtree  search  operation,  an  alias  has  been  encountered 
which  would  lead  to  a  loop  (i.e.,  the  alias  points  to  an  entry  which  is 
superior  to  entries  which  have  already  been  evaluated  in  earring  out  the 
search). 

E-ALIAS-PROBLEM 

An  alias  has  been  encountered,  but  the  entry  to  which  it  points  does  not 
exist. 

E_A.RG_BOUNDS 

The  argument  does  not  comply  with  pragmatic  constraints  (defined  locally 
or  by  functional  standards). 

E^RGJSYNTAX 

An  operation  argument  either  has  incorrect  ASN.l  encoding  or  it  has  cor- 
rect ASN.l  encoding,  but  does  not  comply  to  the  syntax  as  defined  in  the 
Directory  Documents.  Note: 

1.  Within  BindArgument,  additional  elements  are  permitted,  to  allow 
future  extensions,  and  do  not  create  an  error  situation. 

2.  Errors  within  attribute  values  are  not  included  in  this  codification 
(see  E_ATT_SYNTAX). 

J?    A  "D IT'T/^T 

til  J\ixyj_\ lUL 

An  operation  argument  has  correct  syntax,  but  it  violates  additional  rules 
and  constraints  levied  by  the  Directory  Documents  (e.g.,  use  of  a  Priority 
int^^p^^r  vfllnp  who^ip  mepninp"  is  unnennedi  Note* 

1.  Within  a  Relative  Distinguished  Name,  having  two  AVAs  of  the  same 
attribute  type  is  an  error  which  is  covered  by  E_DN,  and  not  by 
E_ARG-VIOL. 

2.  Errors  within  attribute  values  are  not  included  in  this  codification 
(see  E_ATT^YNTAX). 

Ej^TT-BOUNDS 

An  attribute  value  does  not  comply  with  bounds  specified  either  by  the 
Directory  Documents  or  by  functional  standards. 

e_att-Or_valuej:xists 

Within  an  entry,  an  attribute  or  attribute  value  already  exists,  causing  an 
error  situation. 
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Table  10  -  Error  Symptoms  (Part  2  of  3) 


Symptom 

Descripton 

E_ATTJSYNTAX 

An  attribute  value  either  has  incorrect  ASN.l  encoding  or  it  has  correct 
ASN.l  encoding  but  does  not  comply  witht  the  ASN.l  encoding  defined  by 
the  attribute  type. 

T?  ATT  VA  T  TTP 

An  attribute  value,  although  of  correct  ASN.l  encoding,  and  conformant 
with  the  syntax  defined  for  the  attribute  type,  is  not  compliant  with  other 
rules  (e.g.,  a  non-ISO  3166  country  name  encoding). 

E_ACCESS 

The  initiator  has  insufficient  access  rights  to  carry  out  this  operation. 

The  authentication  offered  does  not  match  that  required  by  the  object  being 
authenticated. 

E_BUSY 

Tne  r^S A  19  unable  to  nannle  tni*?  nr»f*ratir»Ti  at.  tni^  t.Tme  (but.  it  tti^v  ne 

able  to  do  so  after  a  short  while). 

E_CHAIN 

The  DSA  needs  to  use  chaining  to  carry  out  this  operation,  but  is  prohibited 
from  doing  so  by  Service  Controls. 

E.CREDENTIALS 

The  credentials  offered  do  not  match  those  of  the  object  with  which  au- 
thentication is  taking  place. 

EJDBE 

An  inconsistency  has  been  detected  in  the  DSA's  data  base,  which  may  be 
localized  to  a  particular  entry  or  set  of  entries. 

An  attempt  was  made  via  an  add  operation  to  place  an  entry  in  the  DIB 
whose  object  class  would  violate  the  DIT  structure  rules. 

A  DN  contains  an  RDN  with  two  AVAs  of  the  same  attribute  type. 

A  DSA  to  which  chaining  is  taking  place  is  unable  to  respond. 

"P  VMTT3V  TTYTCTC 

An  entry  of  the  given  name  already  exists,  causing  an  error. 

E_EXTENSION 

A  DSA  was  unable  to  satisfy  a  request  because  one  or  more  critical  exten- 
sions were  not  available. 

EJLLEGAL-ROOT-OBJ 

Root's  DN  has  been  supplied  as  the  object  of  a  Read,  Compare,  AddEntry, 
RemoveEntry,  ModifyEntry,  ModifyRDN,  or  as  the  Base  Object  of  a  single 
level  search. 

EJLLEGAL.ROOT.VAL 

Root's  DN  has  been  supplied  illegally  as  an  attribute  value  (e.g.,  as  an 
Aliased  Object  Name). 

E.LOOP 

A  loop  has  been  detected  in  the  knowledge  information  within  the  system. 

E-MATCH 

The  attribute  specified  does  not  support  the  required  matching  capability. 

E_MISSING_AVA 

When  creating,  or  after  modifying,  an  entry,  an  AVA  in  the  entry's  RDN 
is  not  represented  within  the  entry's  set  of  attributes. 

EJvlISSING.OBJECT.CLASS 

When  creating  an  entry,  the  entry  does  not  possess  an  object  class. 

E_MULTI_DSA 

The  operation  is  an  update  operation  which  affects  other  DSAs. 

E_NAMING-VIOLATION 

The  name  of  the  new  or  modified  entry  is  incompatible  with  its  object  class. 

E_NON_LEAF.OPERATION 

The  operation  being  attempted  is  illegal  except  on  a  leaf. 

E_NONNAMING_ATTRIBUTE 

In  either  an  add  or  ModifyRDN  operation,  an  attribute  is  included  in  the 
last  RDN  that  is  not  a  valid  naming  attribute  according  to  the  DIT  struc- 
ture rules. 

64 


PART  11  -  DIRECTORY  SERVICES  PROTOCOLS    December  1990  (Stable) 


Table  10  -  Error  Symptoms  (Part  3  of  3) 


Symptom 

Descriptor! 

E-NOT_SINGLE_  VALUED 

An  attribute,  registered  as  single-valued,  has  been  found  with  more  than 
one  value. 

E_NO^UCH_ATT 

The  specified  attribute  has  not  been  found. 

E_NO_SUCH_OBJECT 

Ihe  specified  entry  has  not  been  found. 

E_NO^UCH_VALUE 

The  specified  attribute  value  has  not  been  found. 

E_OBJECT_CLASS-MOD 

An  (illegal)  attempt  has  been  made  to  alter  or  remove  an  object  class 
attribute. 

E_OBJECT_CLASS.VIOL 

There  is  a  schema  violation  (e.g.,  missing  mandatory  attribute,  or  non- 
allowed  attribute  present). 

XA  X^  X^  X^  X^  X^     T  *~«x^ 

E_REFERENCE 

An  erroneous  reference  has  been  detected  (e.g.,  DSA  cannot  handle  name 
even  as  far  as  the  number  of  RDNs  that  have  already  been  resolved). 

E_SCOPE 

No  referrals  were  available  within  the  requested  scope. 

E_SYSTEM_PERM 

A  serious  and  permanent  software  or  system  error  has  been  detected  which 
prevents  completion  of  the  operation. 

E-SYSTEM_TEMP 

A  serious  but  temporary  software  or  system  error  has  been  detected  which 
prevents  completion  of  the  operation. 

E-TIMEOUT 

The  operation  has  not  completed  within  the  allotted  time. 

E.UNABLE_TO.COMPLETE 

The  DSA  is  unable  to  complete  this  operation,  or  others  like  it  (this  applies 
particularly  to  search). 

E.UNABLE.TOJROCEED 

The  DSA  cannot  satisfy  the  operation  after  receiving  it  on  the  basis  of  a 
valid  non-specific  subordinate  reference. 

E_UNDEFINED.ATT 

An  unregistered  attribute  has  been  encountered. 

E.UNSUPPORTED.OC 

The  object  class  of  the  entry  is  not  supported  as  a  valid  object  class  for 
entries  within  this  DSA. 

E.VERSION 

An  unexpected  version  has  been  found  in  Bind. 

E_ZERO_VALUES 

An  attribute  has  been  found  (e.g.,  as  a  result  of  a  modify-entry  operation) 
with  no  values. 

65 


PART  11  -  DIRECTORY  SERVICES  PROTOCOLS    December  1990  (Stable) 


Table  11  -  Error  Situations. 


Situation 

Description 

BIND-LOCAL 

A  bind  is  being  attempted;  either  the  entry  named  is  (or  should  be) 
within  a  local  naming  context,  or  name  resolution  is  being  carried 
out  on  the  part  of  the  name  that  is  known  locally. 

rilJN  U-Kr/MU  1  ti 

A  bind  is  being  attempted,  and  the  entry  named  is  not  within 
a  local  naming  context;  remote  validation  of  credentials  is  being 
carried  out. 

NAME-RESOLUTION 

Name  resolution  is  being  carried  out. 

ADD-ENTRY-NAME-RESOLUTION 

During  an  add  entry  operation,  name  resolution  has  been  success- 
fully accomplished  on  the  superior  object,  and  is  not  being  carried 
out  to  determine  whether  the  new  entry  already  exists. 

ADD-ENTRY 

The  entry  is  being  generated. 

MODIFY-ENTRY 

The  entry  is  being  modified. 

MODIFY-RDN 

The  RDN  is  being  modified. 

REMOVE-ENTRY 

The  entry  is  being  removed. 

READ 

The  entry  is  being  read. 

COMPARE 

A  Compare  operation  is  being  carried  out  on  the  entry. 

LIST 

A  List  operation  is  being  carried  out  on  the  entry. 

SEARCH-FILTER 

A  Search  operation  is  being  carried  out;  the  filter  is  being  evaluated 
or  acted  upon. 

SEARCH-ENTRY 

A  Search  operation  is  being  carried  out;  the  required  entry  infor- 
mation is  being  evaluated  or  acted  upon. 

ABANDON 

An  Abandon  operation  is  being  carried  out. 

TRACE-EVALUATION 

The  trace  element  is  being  evaluated  for  loops. 
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Table  12  -  Notation  Used  to  Describe  Error  Actions. 


Error  Action 
Notation 


Meaning 


Rej 


A  reject  operation  is  generated,  with  problem  mistyped-argument. 


Ah{<  qualifier>) 


Abandon  Failed  Error  is  generated.  The  qualifier  may  take  on  values  codified  as 
follows: 


CA  —  Cannot  abandon 
TL     —  Too  late 


NSO  —  No  such  operation 


A[<  qualifier>) 


Attribute  Error  is  generated.  The  qualifier  may  take  on  values  codified  as  foUows: 


AVE  -  Attribute  or  value  already  exists 
IAS    —  Invalid  attribute  syntax 
NSA  -  No  such  attribute 


CV     -   Constraint  violation 
IM      —  Inappropriate  matching 
UAT  -  Undefined  attribute  type 


N(<  qualifier>) 


NameError  is  generated.  The  qualifier  may  take  on  values  codified  as  foUows: 


ADP  —  Alias  dereferencing  problem 
IAS    —  Invalid  attribute  syntax 


AP  —  Alias  problem 
NSO  -  No  such  object 


SC{<  qualifier>) 


Security  Error  is  generated.  The  qualifier  may  take  on  values  codified  as  follows; 


lA      —  Inappropriate  authentication 
IC      —  Invalid  credentials 
NI     -  No  information 


lAR    —  Insufficient  access  rights 
IS      -  Invalid  signature 
PR     -  Protection  required 


S{<qualifier>) 


Service  Error  is  generated.  The  qualifier  may  take  on  values  codified  as  foUows: 


ALE  - 

Administrative  limit  exceeded 

B 

Busy 

CR  - 

Chaining  required 

DE  - 

Dit  Error 

IR  - 

Invalid  reference 

LD  - 

Loop  detected 

DOS  - 

Out  of  Scope 

TLE  - 

Time  limit  exceeded 

UA  - 

Unavailable 

UAP  - 

Unable  to  proceed 

UCE  - 

Unavailable  critical  extension 

UWP  - 

Unwilling  to  perform 

V  [<  qualifier>) 


Update  Error  is  generated.  The  qualifier  may  take  on  values  codified  as  follows: 


AMD  -  Affects  multiple  DSA 

NAN  —  Not  allowed  on  non-leaf 

NV     -  Naming  violation 

OMP  -  Object  class  modification  prohibited 


"ST" 


EAE  —  Entry  already  exist 
NAR  -  Not  allowed  on  RDN 
OCV  -  Object  class  violation 
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Table  13  -  Error  Actions  (Part  1  of  6) 


Situation  (See  Table  11) 

Symptom 

Bind- 

Add-Entry- 

(^oee  laDie  iu j 

Bind- 

Remote- 

Name- 

Name- 

T  .1 

L/ocal 

Resolution 

Resolution 

Resolution 

A  J  J    T7>  J.  

Add-il/ntry 

Modiiy-iiyntry 

SC(IAR)(14) 

SC(IAR)(14) 

SC(IAK)(14) 

SC(IAR)(14) 

XT    A'PVA/TTXT  T  TIV^fTT^ 

iii_AiJMlJN  _blMi  i 

C  /  T  T  A  \ 

b(  U  A) 

O  /  T  T  A  ^ 

b(UA) 

S(  ALE) 

S(ALE) 

S(ALE) 

S(ALE) 

T?    A  T  T  A  C  rM^Dim^ 

Hi-ALilAb-UlljKlljr 

S(IC) 

S(IC) 

XT/  A  T^T^  \ 

N(ADP) 

17    ATTAC   T  r\r\'D 

U*    ATTAC  DT5r^DTt?A/f 

111  _A.  Li  i  A  b  _r  K  U  rJ  Li  Cj  M 

S(IC) 

S(IC) 

1n(AF) 

ni  _A  r\  Lj  _t>    U  IN  U  b 

(8) 

(7) 

b(U  Wl-')(12) 

b(  U  Wr  )(12j 

b(u  WJr  j(12) 

b^U  WF 

TT    A  T>  CVMT'A'V" 

lli_aK(j_b  I  IN  i AA 

(^\ 

(^  \ 
U) 

rtej 

rtej 

rtej 

rtej 

(1) 

(1) 

Rej 

Rej 

Rej 

Rej 

Ej^TT_BOUNDS 

SC(IC) 

(7) 

N(IAS)  . 

N(IAS) 

A(CV) 

A(CV) 

E_ATT.OR.VALUE_EXISTS 

A(AVE) 

A(AVE) 

E-ATT.SYNTAX 

SC(IC) 

(7) 

N(IAS) 

N(IAS) 

A(IAS) 

A(IAS) 

E,J\.TT.VALUE 

SC(IC) 

(7) 

N(IAS) 

N(IAS) 

A(IAS) 

A(IAS) 

E_AUTHENTICATION 

SC(IA) 

SC(IA) 

E-BUSY 

S(UA) 

S(UA) 

S(B) 

S(B) 

S(B) 

S(B) 

E-CHAIN 

S(CR) 

E-CREDENTIALS 

SC(IC) 

SC(IC) 

E_DBE 

S(UA) 

S(UA) 

S(DE) 

S(DE) 

S(DE) 

S(DE) 

EJDIT.STRUCTURE 

U(NV) 

E_DN 

SC(IC) 

SC(IC) 

N(NSO) 

C(NV) 

EJDSA 

S(UA) 

S(UA) 

S(UA) 

E_ENTRY.EXISTS 

U(EAE) 

E_EXTENSION 

S(UWP) 

S(UCE) 

S(UCE) 

S(UCE) 

EJLLEGALJIOOT-OBJ 

SC(IC) 

SC(IC) 

N(NSO) 

N(NSO) 

N(NSO) 

EJLLEGAL_ROOT_VAL 

SC(IC) 

(7) 

N(IAS) 

N(IAS) 

A(IAS) 

A(IAS) 

E_LOOP 

S(UA) 

S(LD) 
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Table  13  -  Error  Actions  (Part  2  of  6) 


Situation  (See  Table  11) 

Symptom 

Bind- 

Add-Entry- 

(See  Table  10) 

Bind- 

Remote- 

Name- 

Name- 

Local 

Resolution 

Resolution 

Resolution 

Add-Entry 

Modify-Entry 

EJvIATCH 

SC(IC) 

SC(IC) 

A(IM) 

A(IM) 

A(IM) 

EJVIISSING-AVA 

U(NAR) 

U(NAR) 

E_MISSING-OBJECT.CLASS 

U(OCV) 

U(OMP) 

E-MULTI_DSA 

S(AMD) 

E-NAMING-VIOLATION 

U(NV) 

EJ^ON-LEAF.OPERATION 

E-NONNAMING.ATTRIBUTE 

U(NV) 

E_NOT-SINGLE.  VALUED 

A(CV) 

A(CV) 

E_NO-SUCH-ATT 

A(NSA) 

E-NO-SUCH.OBJECT 

SC(IC) 

SC(IC) 

N(NSO) 

E_NO.SUCH- VALUE 

A(NSA) 

E-OBJECT-CLASS^MOD 

U(OMP) 

E-OBJECT-CLASS-VIOL 

U(OCV) 

U(OCV) 

E-REFERENCE 

S(UA) 

S(IR) 

E_SCOPE 

S(OOS) 

E-SYSTEM-PERM 

S(UA) 

S(UWP) 

S(UWP) 

S(UWP) 

S(UWP) 

E.SYSTEM.TEMP 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

E.TIMEOUT 

S(UA) 

(9) 

S(TLE) 

S(TLE) 

S(TLE) 

S(TLE) 

E.UNABLE_TO.COMPLETE 

E.UNABLE.TOJ>ROCEED 

(2) 

(2) 

E.UNDEFINED.ATT 

SC(IC) 

(3) 

U(NV) 

A(UAT) 

A(UAT) 

E.UNSUPPORTED-OC 

U(OCV) 

E-VERSION 

S(UA) 

E-ZERO-VALUES 

A(CV) 

A(CV) 
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Table  13  -  Error  Actions  (Part  3  of  6) 


(See  Table  10) 

Situation  (See  Table  11) 

RDN 

Remove- 
Entry 

Read 

Compare 

Trace 
Evaluation 

EJ\.CCESS 

SC(IAR)(14) 

SC(IAR)(14) 

SC(IAR)(14) 

SC(IAR)(14) 

E_ADMIN  .LIMIT 

S(ALE) 

S(ALE) 

S(ALE) 

E_A.LIAS-DEREF 

EJ\.LIAS-LOOP 

E_A.LIAS_PROBLEM 

E_A.RG30UNDS 

S(UWP)(12) 

S(UWP)(12) 

S(UWP)(12) 

E_A.RG^YNTAX 

Rej 

Rej 

Rej 

Rej 

Rej 

EJIlRG_VIOL 

Rej 

Rej 

Rej 

Rej 

Rej 

EJ1lTT_BOUNDS 

N(IAS) 

A(CV) 

(7) 

e^tt.or.value.exists 

EJ\.TT  .SYNTAX 

N(IAS) 

A(IAS) 

(7) 

EJ\.TT.VALUE 

N(IAS) 

A(IAS) 

(7) 

E.AUTHENTICATION 

E3USY 

S(B) 

S(B) 

S(B) 

S(B) 

E.CHAIN 

E-CREDENTIALS 

EJDBE 

S(DE) 

S(DE) 

S(DE) 

S(DE) 

EJ3IT.STRUCTURE 

EJ)N 

A(CV) 

A(IAS) 

EJDSA 

E.ENTRY.EXISTS 

U(EAE) 

EJIXTENSION 

S(UCE) 

S(UCE) 

S(UCE) 

S(UCE) 

EJLLEGALJIOOT.OBJ 

N(NSO) 

N(NSO) 

N(NSO) 

N(NSO) 

EJLLEGALJIOOT.VAL 

N(IAS) 

A(IAS) 

(7) 

EXOOP 
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Table  13  -  Error  Actions  (Part  4  of  6) 


Symptom 
I  Dec  xauic  iu  1 

Situation  (See  Table  11) 

Modify- 
rtUlN 

Remove- 
Entry 

Kead 

Compare 

Trace- 
Evaluation 

E  MATCH 

A  ^TA/TX 

A(IM) 

in 

EJMISSING^AVA 

E_MISSING  OBJECT  CLASS 

EJVIULTI  DSA 

CI  A  AAn^ 

c/"  A  ^^^^^ 

EJ^IAMING  VIOLATION 

U^lN  V  ) 

E  NON  LEAF  OPERATION 

TI^N  A  N^ 

E_NONNAMING.ATTRIBUTE 

E-NOT-SINGLE.VALUED 

A(CV) 

E_NO_SUCH.ATT 

A(NSA)(4) 

A(NSA)(4) 

EJSIO_SUCH_OBJECT 

E_NO-SUCH_VALUB 

E-OBJECT-CLASS-MOD 

E-OBJECT-CLASS-VIOL 

U(OCV) 

E-REFERENCE 

E-SCOPE 

E-SYSTEM-PERM 

S(UWP) 

S(UWP) 

S(UWP) 

S(UWP) 

S(UWP) 

E^YSTEM.TEMP 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

E.TIMEOUT 

S(TLE) 

S(TLE) 

S(TLE) 

S(TLE) 

E.UNABLE.TO.COMPLETE 

E.UNABLE.TO.PROCEED 

E.UNDEFINED_ATT 

A(UAT) 

A(NSA)(4) 

A(NSA) 

(7) 

E-UNSUPPORTED-OC 

E_VERSION 

E^ERO-VALUES 

(11) 

71 


PART  11  -  DIRECTORY  SERVICES  PROTOCOLS    December  1990  (Stable) 


Table  13  -  Error  Actions  (Part  5  of  6) 


(<i(.f.  Table  1  0"! 

Situation  (See  Table  11) 

T  icf 

1  L  11 UCZ  t 

oc&rcri 

D  e  circii 

E_ACCESS 

SC(IAR)(14) 

SCfIAR'>Cl4"l 

SC(IAR)(14) 

E_ADMIN.LIMIT 

SCALEVlS"* 

t  Ji-  i—J  I— J  J\  A.  I 

Sf  ALEVlSt 

EjVLIAS_DEREF 

\^  1 

E_ALIAS_LOOP 

E_ALIAS_PROBLEM 

E-A.RG_BOUNDS 

E_A.RG^YNTAX 

Rej 

Rei 

Rei 

Rej 

E-ARG-VIOL 

Rej 

Rej 

Rej 

E_A.TT30UNDS 

A(CV) 

E-ATT.OR.VALUE-EXISTS 

Ej^.TT_SYNTAX 

A(IAS) 

E_ATT_VALUE 

A(IAS) 

e_a.uthentication 

E_BUSY 

S(B) 

S(B) 

S(B) 

E-CHAIN 

E-CREDENTIALS 

EJDBE 

S(DE) 

S(DE) 

S(DE) 

EJDIT.STRUCTURE 

EJDN 

A(IAS) 

EJDSA 

(5) 

EJINTRY.EXISTS 

E_EXTENSION 

S(UCE)(13) 

S(UCE)(13) 

S(UCE)(13) 

EJLLEGALJlOOT_OBJ 

(10) 

EJLLEGAL-ROOT.VAL 

A(IAS) 

E-LOOP 

(5) 
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Table  13  -  Error  Actions  (Part  6  of  6) 


Symptom 
(See  Table  10) 

Situation  (See  Table  11) 

List 
(Filter) 

Search 
(Filter) 

Search 
Entry 

Abandon 

E3^ATCH 

A(IM) 

EJV[ISSING-AVA 

EJVIISSING_OBJECT-CLASS 

E_MULTI.DSA 

E_NAMING-VIOLATION 

E_NON-LEAF_OPERATION 

E_NONNAMING.ATTRIBUTE 

E_NOT.SINGLE.  VALUED 

E_NO_SUCH.ATT 

E_NO_SUCH_OBJECT 

E_NO.SUCH.  VALUE 

E.OBJECT_CLASS-MOD 

E.OBJECT_CLASS.VIOL 

E_REFERENCE 

EJSCOPE 

EJSYSTEM_PERM 

S(UWP) 

S(UWP) 

S(UWP) 

Ab(CA) 

E^YSTEM.TEMP 

S(UA) 

S(UA) 

S(UA) 

Ab(CA) 

E.TIMEOUT 

S(TLE)(13) 

S(TLE)(13) 

S(TLE)(13) 

E.UNABLE.TO.COMPLETE 

S(B) 

S(B) 

S(B) 

Ab(CA) 

E.UNABLE.TO.PROCEED 

E.UNDEFINED.ATT 

(6) 

(6) 

E_UNSUPPORTED_OC 

E-VERSION 

EJZERO-VALUES 
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Notes  for  table  13 

1.  Use  A-U- ABORT.  Note,  however,  that  extra  elements  are  permitted  here. 

2.  An  "unable-to-proceed"  error  becomes  SC(IC)  for  bind  and  N(NSO)  for  operations 
if  no  DSA  contacted  can  located  the  object. 

3.  An  undefined  attributed  encountered  during  name  resolution  is  only  an  error  - 
N(NSO)  -  if  the  entry  is  identified  as  local.  See  cilso  Note  10  below. 

4.  The  A(NSA)  condition  is  reserved  in  the  case  of  "read"  for  the  situation  when  no 
attribute  of  the  specific  list  provided  can  be  returned  (for  reasons  that  include  security 
errors). 

5.  Any  failure  to  propagate  a  search  causes  abandonment  of  that  part  of  the  search. 

6.  Undefined  attributes  are  regarded  as  not  matched  or  found,  but  cause  no  errors  in 
search. 

7.  This  error,  if  detected,  should  be  ignored;  processing  continues. 

8.  This  error  would  occur  as  a  result  of  a  bind  argument  with  a  name  containing  too 
many  RDNs  for  the  DSA.  Use  either  S(UA)  or  S(IC). 

9.  DSAs  should  use  the  time-limit  service  control  with  local  timeout  to  limit  the  remote 
validation  of  credentials;  if  the  operation  fails  as  a  result,  S(UA)  is  used. 

10.  For  a  single-entry  search,  N(NSO)  may  be  used. 

11.  Either  the  whole  attribute  should  be  removed,  or  the  deleteOldRDNflag  should  be 
ignored. 

12.  Wherever  S(UWP)  appears  in  the  above  tables  beside  E.ARG_BOUNDS,  a  ROSE 
"Rej"  is  also  admissible. 

13.  The  error  is  returned  when  there  are  no  partial  results,  otherwise  a  partialOutcome- 
Qualifier  with  the  appropriate  limitProblem  is  returned  (cf  Directory  Documents,  Part 
3,  item  g  of  clause  12.8.2,  and  Part  3,  clause  10.1.3.3.1). 

14.  In  every  case  where  a  security  error  occurs,  except  in  bind,  SC(NI)  may  be  used 
in  place  of  the  specified  problem,  to  support  a  Security  Policy  which  states  that  no 
information  on  the  problem  may  be  divulged.  In  the  case  of  the  bind,  SC(NI)  is  not 
available. 
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Table  14  -  Simple  Credential  Fields  and  Protected  Simple  Authentication 


SimpleCredential  Field 

Equivalent  Notation 

in  Directory  Documents, 

Part  8,  figure  2 

name 

A 

timel 

^1 

time2 

random  1 

random2 

password 

protected2 
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PART  12  -  SECURITY 


March  1991  (Stable) 


Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Security  Special  Interest  Group 
(SECSIG)  of  the  National  Institute  of  Standards  and  Technology  (NIST)  Workshop  for  Implementors  of  Open 
Systems  Interconnection  (OSI).  See  Procedures  Manual  for  Woprkshop  charter. 

Text  in  this  part  has  been  approved  by  the  Pieanary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject.  There  is  significant  technical  change  from  this  text  as 
previously  given. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  struck.  New  and  replacement  text  will  be  shown  as 

shaded. 
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Part  12  -  Security 

iditOr'$  Nolo  -  Previous  material  in  thts  part  h9$  been  t^eleted  ^nd  i$  no  longer  9pplH<M^i 

0  Introduction 

1  Scope 

2  Normative  References 

[1]       ISO/IEC  9594-8  (CCITT  X.509  Recommendation)//7formaf/on  Technology  -  Open  Systems 
Interconnection  -  The  Directory  -  Part  8:  Authentication  Framework. 

[2]       ISO  8649:  1988/DAD  1  Service  Definition  for  the  Association  Control  Sen/ice  Element,  Addendum 
1:  Peer-Entity  Authentication  During  Association  Establishment. 

[3]       ISO  8650:  1988/DAD  1  Protocol  Specification  for  the  Association  Control  Sen/ice  Element, 
Addendum  1:  Peer-Entity  Authentication  During  Association  Establishment. 

[4]       ISO/IEC  9594-3  (CCITT  X.511  Recommendation)  Information  Technology  -  Open  Systems 
Interconnection  -  The  Directory  -  Part  3:  Abstract  Sen/ice  Definition. 

[5]       ISO   10021-4   (CCITT  X.411    Recommendation)  Information  Processing  Systems  -  Text 
Communication  -  MOT/S  -  Message  Transfer  System  :  Abstract  Sen/ice  Definition  and  Procedures. 

[6]       ISO  7498-2  Information  Processing  Systems  -  Open  Systems  Interconnection  Reference  Model  - 
Part  2:  Security  Architecture,  February  1989. 

3  Definitions 

4  Symbols  and  Abbreviations 
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5  Architectures 

5.1  Introduction 

5.2  General  OIW  Application  Environments 

5.3  Security  Profiles 

5.4  Guidelines  for  OIW  Application  Profile  Development 

6  Key  Management 

7  Lower  Layers  Security 

8  Upper  Layers  Security 

9  Message  Handling  System  (MHS)  Security 

All  current  MHS  security  relevant  text  appears  in  Part  8,  clause  11. 

10  Directory  Services  Security 

11  Network  Management  Security 
11.1  Threats 
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11.3    Security  Mechanisms 


12  Security  Aigoritiims 

12.1  Integrity 

12.1.1  MD4Hash 

12.1.2  SQ-Mod-N 

!  Recent  research  regarding  the  square-mod-n  one-way  hash  function  described  in  Annex  D  of  the  Directory 
j  Documents,  ISO  9594  -  Part  8,  has  revealed  that  the  function  is  not  secure.  Its  use,  therefore,  is 
!  discouraged. 

;  12.1.3      DES  MAC 

12.2  Authentication 

12.2.1      MD4  with  RSA  Signature 

NOTE  -  This  text  was  moved  from  Part  11,  dause  14, 


I  12.2.2  EIGamal 

I  The  Information  in  this  subclause  includes  a  tutorial  description  of  the  EIGamal  scheme  for  digital  signature 

j  using  the  notation  defined  in  the  Directory  Documents,  ISO  9594  -  Part  8.  It  is  intended  that  much  of  the 

j  tutorial  information  provided  in  this  subclause  will  be  moved  to  the  security  agreements  sometime  in  the 

I  future. 


j  12.2.2.1  Background 

I  The  EIGamal  digital  signature  scheme  is  based  on  earlier  work  done  by  Diffie  and  Hellman  [DIFF76]  in  which 
it  was  suggested  that  a  likely  candidate  for  a  one-way  function  is  the  discrete  exponential  function 


/(x)«a*(modp) 


(1) 
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where  x  is  an  integer  between  1  and  p-1  inclusive,  wliere  p  is  a  very  large  prime  number,  and  where  o  is 

an  integer  such  that  1<a>p  and  {a  mod  p,  a  mod  p,  mod  p}  is  equal  to  the  set  {1,  2  p-1}.  In 

algebraic  terminology,  such  an  a  is  called  a  primitive  element.  References  on  the  topic  of  primitive  roots  and 
elements  are  [McCI79]  and  [PATT87]. 

Now,  in  the  real  number  system,  if  y  =  a,  then  by  definition  of  the  logarithm  we  can  solve  for  x  using  x  = 
'oga(/)-  The  same  idea  extends  to  solving  eq  (1)  for  x  so  that  inverting  /(x)  requires  calculating  discrete 
logaritfims.  The  reason  Diffie  and  Hellman  suspected  eq  (1)  is  one-way  is  that  for  suitable  p,  it  is 
computationally  difficult  to  invert  According  to  the  current  state  of  the  art,  computing  discrete  logs  for 
suitable  p  has  been  found  to  require  a  number  of  operations  roughly  equivalent  to 


where  b  is  the  number  of  bits  in  p,  and  c  is  estimated  at  c  =  .69  according  to  [ODLY].  This  can  be 
compared  to  only  about  2  logg  p  multiplications  for  discrete  exponentiation.  If  in  fact  the  best  known 
algorithm  for  computing  discrete  logs  is  near  optimal  then  Expression  (2)is  a  good  measure  of  the  problem's 
complexity  (for  a  properly  chosen  p)  and  the  discrete  exponential  function  has  all  the  qualities  of  a  one-way 
function  as  described  by  Diffie  and  Hellman. 


12.2.2.2       Digital  Signature 

Private  Key:  denotes  the  private  key  for  user  X.  X^  is  a  randomly  chosen  integer  which  user  X  keeps 
secret. 

Public  Key:  X^  denotes  the  public  key  for  user  X  and  is  calculated  using  the  corresponding  private  key  such 
that 


a)  p  is  a  prime  satisfying  the  requirements  listed  in  12.2.2.4. 

b)  a  is  a  primitive  element  mod  p. 

c)  Note  that  p  and  a  could  be  used  globally,  but  because  they  should  be  easily  changeable  (see 
12.2.2.4  for  information  about  why  these  two  parameters  should  be  easily  changeable)  it  would 
probably  be  preferable  for  each  user  to  choose  his/her  own  p  and  a.  If  users  choose  their  own, 
then  p  and  o  must  be  made  available  to  the  recipient  for  use  in  the  signature  verification  process. 

Signing  Procedure:  Suppose  user>4  wants  to  sign  a  message  intended  for  recipient  B.  The  basic  idea  is  to 
compute  a  two  part  signature  (r,  s)  for  the  message  m  such  that 


expi/cttnb) 


(3) 


where 


a 


M'n)=(Ap)V*(modp) 


(4) 


where  /?  is  a  one-way  hash  function. 


Compute  the  signature  (r,  s)  as  follows. 
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a)  Choose  a  random  number  k,  uniformly  between  0  and  p-1  such  that  k  and  p-1  have  no  common 
divisor  except  1  (i.e.,  gcd(/(,p-1)  =  1). 

b)  Compute  r  such  that 

/^a*(modp)  (5) 

c)  Use  r  to  solve  for  the  corresponding  s  as  follows. 

1)  rewrite  eq  (4)  using  eq  (5)  and  the  definition  of  the  public  key  to  get 

a/'(m).aWr«/«(modp)  (6) 
Combining  exponents,  get 

«/K/»«.„W^*'«(modp)  (7) 

eq  (7)  implies  that 

/j(m)=(>4^/'+A^s(modp-1)  (8) 

Note  that  eq  (8)  has  a  single  solution  for  s  because  k  was  chosen  such  that  gcd(/(,p-1)  =  1 . 
See  [SIER88]  for  supporting  theorem. 

2)  now  solve  for  s  and  get 

s^l{him)-{A^i)imodp-1)  (9) 
I  where  /  is  computed  such  that  /(  *  /  =  1  (mod  p-1). 

The  EIGamal  signature  is  comparable  in  size  to  the  corresponding  RSA  signature. 

I 

12.2.2.3  Verification 

L  The  recipient  receives  Ap,  m,  r,  s,  a,  and  p  and  computes  both  sides  of  eq  (4)  and  then  compares  the 
'I  results. 

I 

12.2.2.4  Known  Constraints  on  Parameters 

The  following  list  of  constraints  is  the  result  of  a  search  of  current  literature  and  may  not  be  complete, 
[f  a)  p  must  be  prime 

b)  p  must  be  large. 

Note  that  Expression  (2)  can  be  used  to  speculate  on  the  level  of  security  afforded  by  crypto 
systems  based  on  the  discrete  log  problem.  Breaking  the  EIGamal  scheme  has  not  been  proven  to 
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be  equivalent  to  finding  discrete  logs,  but  if  we  assume  equivalence  then  we  can  estimate  how  large 
p  should  be  for  a  desired  level  of  security. 

For  instance.suppose  we  wanted  to  use  Expression  (2)  to  decide  how  large  p  should  be  so  that  we 
can  be  reasonably  sure  the  system  cannot  be  broken  (using  the  best  known  algorithm)  in  a  practical 
amount  of  time.  To  be  on  the  conservative  side,  we  decide  we  want  to  protect  against  a  special 
purpose  machine  that  can  perform  10^^  operations  per  second.  Specifically,  we  want  to  know  how 
large  p  should  be  so  that  such  a  machine  would  take  at  least  one  year  to  break  the  system. 

In  one  year,  the  hypothetical  machine  can  perform  3x10^  operations.  To  find  the  size  of  the 
desired  p,  solve  the  following  equation  for  b. 

We  get  ^"606  jhis  is  the  number  of  bits  in  the  desired  p.  So,  the  magnitude  of  the  desired  p  is 
about  2^  which  is  roughly  266  x  10'®° 

Hence,  to  be  reasonably  sure  of  attaining  the  desired  level  of  security,  we  find  a  prime  number 
greater  than  266  x  10^®°  which  satisfies  all  the  other  criteria  listed  in  this  subclause.  Our  confidence, 
however,  is  strictly  based  on  the  assumption  that  breaking  EIGamal  is  as  difficult  as  finding  discrete 
logs  and  the  assumption  that  the  best  known  algorithm  for  finding  discrete  logs  is  near  optimal. 

c)  p  should  occasionally  be  changed.  This  requirement  is  discussed  in  [ODLY84]  and  is  related  to 
the  discovery  of  new  algorithms  for  computing  discrete  logarithms  in  GF(p). 

d)  p-1  must  have  at  least  one  large  prime  factor.  This  requirement  is  discussed  in  [0DLY84]  and 
is  imposed  by  the  Silverman-Pohlig-Hellman  algorithm  p  which  computes  discrete  logarithms  in 

GF(p)  using  on  the  order  operations  and  a  comparable  amount  of  storage,  where  r  is  the  largest 
prime  factor  in  p-1 . 

e)  p  should  not  be  the  square  of  any  prime.  A  subexponential-time  algorithm  for  computing  discrete 
logarithms  in  GF(p^)  has  been  found.  See  [ELGA85b]for  details. 


12.2.2.5       Note  On  subjectPublicKey 

The  ASN.1  data  element  subjectPublicKey,  defined  as  BIT  STRING  in  Annex  (G)  of  Directory  Documents, 
ISO  9594  -  Part  8,  shall  be  interpreted  in  the  case  of  EIGamal  as  being  type: 

SEQUENCE{  INTEGER,  INTEGER  } 

Where  the  first  integer  is  the  Arithmetic  Modulus  and  the  second  is  the  primitive  element  for  the  finite  field. 
The  sequence  is  represented  by  ASN.1  Basic  Encoding  Rules. 

Implementors  should  take  note  that  the  size  of  the  integers  used  for  these  parameters  is  expected  to  exceed 
the  pragmatic  constraints  specified  for  integers  by  the  upper  layers  SIG. 
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12.2.2.6        Note  On  the  ENCRYPTED  MACRO 

The  value  associated  with  the  ENCRYPTED  MACRO,  as  defined  in  Directory  Documents,  part  8.  clause  8.4 
shall  be  interpreted  in  the  case  of  EIGamal  as  being  type: 

SEQUENCE{  INTEGER,  INTEGER  } 

The  first  integer  in  the  sequence  is  r  (see  eq  (5),  12.2.2.2).  The  second  integer  is  s  (see  eq  (9),  12.2.2.2). 

|iOTE  -  12.2.3  to  12.4.1,  a]ong  wth  fiCKtions     ariripe^^^  not  appeared  in  any  workshop 

documentation  prior:  to  this  t<me. 

12.2.3  FIRS  112  Password  Encryption 

12.2.4  DES  MAC 

12.3  Confidentiality 

12.3.1      DES  In  CBC  Mode  Encryption 

12.4  ASN.1  Definitions 

12.4.1  General  Security  Algorithms 

Refer  to  Part  13,  clause  12.4.1  of  the  Working  Agreements  as  of  March  1991. 

12.4.2  ASN.1  for  Directory  Services  Strong  Authentication  Algorithms 

Editor's  Note  -  The  following  algorithms  were  originally  registered  by  the  Directory  Services  SIG,  hence  the 
Object  ID  remains  dssig(7). 

This  subclause  defines  object  identifiers  assigned  to  authentication  algorithms.  The  definitions  take  the  form 
of  the  ASN.1  module,  "OIWAIgorithmObjectldentifiers". 
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OIWAlgorithmObject Identifiers  {iso(l)  identif ied-orqanization(3 ) 

oiw(14)  dssig(7)  oIWAlgorithmObjectldentif iers ( 1 ) } 
DEFINITIONS  ::= 
BEGIN 

EXPORTS 

md2,  md2WithRSA,  elGamal,  md2WithElGamal ; 

IMPORTS 

authent  i  cat  ionFr amewor k 

FROM  UsefulDef initions  { joint-iso-ccitt  ds(5)  modules(l) 

usef ulDef initions ( 0 ) } 

ALGORITHM 

FROM  AuthenticationFramework  authent icationFramework; 

—  categories  of  object  identifiers 

algorithm  OBJECT  IDENTIFIER  ::=  {iso(l)  identif ied-organization(3) 

oiw(14)  dssig(7)  algor ithm( 2 ) } 

encriptionAlgorithm  OBJECT  IDENTIFIER  ::=  {algorithm  l} 

hashAlgorthm  OBJECT  IDENTIFIER  ::=  {algorithm  2} 

signatureAlgorithm  OBJECT  IDENTIFIER  ::=  {algorithm  3} 

—  algorithms 

md2  ALGORITHM 

PARAMETER  NULL 

::=  {hashAlgorithm  1} 

md2WithRsa  ALGORITHM 
PARAMETER  NULL 

::=  {signatureAlgorithm  1}      .  . 

elGamal  ALGORITHM 
PARAMETER  NULL 
::=  {encryptionAlgorithm  l) 

Editor's  Note:  Refer  to  the  June  1990  Working  Agreements  for  information 
regarding  why  PARAMETER  NULL  is  specified  above  for  the  elGamal 
encryption  algorithm. 

md2WithElGamal  ALGORITHM 
PARAMETER  NULL 
::=  {signatureAlgorithm  2} 

END  —  of  Algorithm  Object  Identifier  Definitions 


Figure  1  -  ASN.1  for  directory  services  strong  authentication 
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Annex  A  (normative)  

ISPICS  Requirements  List 


PART  12  -  SECURITY 


March  1991  (Stable) 


Annex  B  (normative) 
Errata 

Table  1  -  SIA  part  12  changes 


NO.  OF  ERRATA 

TYPE 

REFERENCED  DOCUMENT 

CLAUSE 

NOTES 

TECHNICAL 

SIA  PART  -  12 

0..12 

ADD  OUTLINE  2ND  LEVEL 

TECHNICAL 

SIA  PART  -  12 

9 

ADD  TEXT 

TECHNICAL 

SIA  PART  -  12 

12.1.2 

ADD  TEXT 

TECHNICAL 

SIA  PART  -  12 

12.2.2 

ADD  TEXT 

TECHNICAL 

SIA  PART  -  12 

12.4.1/.2 

ADD  TEXT 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Security  Special  Interest  Group 
(SECSIG)  of  the  National  Institute  of  Standards  and  Technology  (NIST)  Workshop  for  Implementors  of  Open 
Systems  Interconnection  (OSI).  See  Procedures  Manual  for  Woprkshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject.  There  is  significant  technical  change  from  this  text  as 
previously  given. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  struck.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  1 3  -  Security 

Editor's  Note — Previouc  material  in  this  part  has  been  doleted  and  is  no  longor  applicablo. 

0  Introduction 

This  part  is  reserved  for  future  stable  Security  agreemer^ts.  Agreements  may  be  found  in  the  aligned  part 
of  the  Working  Implementation  Agreements  document. 

Editor's  Note  -  The  below  outline  represents  the  planned  clauses  to  move  stable  during  the  Jun  91  OIW. 
Consult  Part  13  of  the  Working  Implementation  Agreements  for  current  information.  The  following  is  the  outline 
which  will  replace  the  text  in  Part  13: 


Table  1  -  Future  Changes  Planned  for  Part  12 


Part  12  -  Stable 

Clause 

Title 

8 

Upper  Layers  Security 

11 

Network  Management  Security 

12 

Security  Algorithms 

1  Scope 

2  Normative  References 

3  Definitions 

4  Symbols  and  Abbreviations 
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5.1  Introduction 

5.2  General  OIW  Application  Environments 

5.3  Security  Profiles 

5.4  Guidelines  for  OIW  Application  Profile  Development 

6  Key  Management 

7  Lower  Layers  Security 

8  Upper  Layers  Security 

This  clause  addresses  tfie  provision  of  security  services  In  the  Upper  tay©rs<  The  Upper  iayws  Security 
MiXtel  speotfle;&  the  Interactions  among  the  Upper  Layers  In  providing  and  using  security  services  {Rel, 
ISO/IEC  CD  10746]. 

8.1     Security  Mechanisms 
MjA       Peer  Entity  Authentication 


AC$E  authentication  extensions  [Ref.  ISO  8649,  ISO 

6^50]  support  two-way  authenticatlor^  through  the 

dei^^lon  of  9  t^ew  iunctlonat  unit. 

When  this  functional 

unit  1$  employed,  additional  parameter$  are  provided 

by  the  A-A$SOCf  ATE  service  to 

ndicate  this 

requirement  and  convey  authenticaUon  infonnsaion  between 

endties.  The  k$HA  d^ltii^  for  this  information  Isiigtlvenibedowii^ 
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from 
AutHe 

atlcatioai               SEQUENCE  { 

tianisat-naae               |03  tltPLlCt^  OBJECT  identifi 

ER  OPTIONAL, 

c 
h 
e 

Reni&i  cat;  i.an,*^  vai.ue 
hatstring 

ther 

Figure  1 

IQ}  IMPLICIT  GraphicStri 
ill  ZtfPhlCm  BXTSTRING, 
12}  IMPLICIT  EXTERNAL, 
C3}  ANY  DEFINID  Blf  mecha 

-  A-ASSOCiATJE  Authentication  informs 

nism-name  }  } 
ition 

Tliese  agreements  define  the  following  mechanisms  for  usa  with  this  ACSE  functtonaJ  unit: 


slmpte^strong  authentication  mechanism. 
8.1.1.1        Simple-Strong  Authentication 


6.1.11.1  OpcH^tlon 


The  operation 

the  simple-strong  i 

authenScatlon  mechanisms  are  based  upon  ISO  96^-3  and  9S§4*8 

Standards. 

The  sending  system 

isl 

hesentitysrequesting  authentication  of  its  identity 

,  and  the  receiving 

si^m  is 

the 

entity 

performing 

the  authentication. 

The  sending  system  supplies  data  for  the  ACSE 

authentication  fMd<Jf  the  A-A$$OCiATE  primitive.  The 

receiving  ACSE  obtains  the  ACSE 

authentication  data 

lr«m  the  A-ASSOCIATE  PDiJ.  and  it  pedonns  the  authentication  check. 

If 

this  check 

fails,  the  receiving 

ACSe  returns  an  A- 

ABOfiT  primitive  to  Ui6  sending  ACSE.  If  the  check 

is  successful,  the  association 

fomiatlon  succeeds 

or  iais  depending  upon  otiw  clrcymstances  and  parameters.  The  use  c 

>l  the  ACSE 

authentication  fields 

support  both  the  simple  ^ind  strong  credentials  variants  of  the  ISO  9594  authentication 

sxdhangesi 

perflcates  for  use  with  strong  authentication  must  be  compatible  with  ISO  9594-8. 

N0T1E  -  Certificates  procured  for  use  wi*»  lntem«  Privacy  Enhanced  Maif  [T8D  r&g^  ar*  cdmptet$iy<X)ftlpatlbte 
with  ISO  9594-8  and  may  {sutojea  to  llcen^  r«st^lons)  \a  u$ed  by  the  strong  authentication  mechanism. 
Hov«ver,  Privacy  Er*tanc6d  Mii  «S€i6  Only  a5i*i6^<)f  the  suggested  ISO  9594-7  name  forms,  and  might  not 
support  «M!taln  narwform$  of  int^ttOSpecJIIcOIWap^llcatiori?.  Examples  include  Application  Entity  names 
and  c*tdln  name  for defined  by  ti^  North  Aftierican  Directory  Forum  in  NADF-123  |ref.  TBp| 

8.1.1.1.2  Data  Structtn^ 

Mechanism  Name 

The  following  is  ^  A$N.1  description  ^  tlie  authentication  data  ^tmcture  for  ^Imple.jor,  atfOjiig 
iu^enScistflon;; 
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>  "  »iffl|>le-»strong-autb~inechanlsin  object  IDENTIFIER  %t«  {iso 

identif ied-organization  (3) 
OIW     ( 4 ) 

SECSIG  (3) 

Autneni; ication-mecnanisma 
simpl^-stcong-identity-authenticatioii  (I) 
} 

Th^  authentloatton  va^u0  is  oonveyed  in  the  tjtJwf  (se^  figure  t)  cptlop  of  the  ^utf»ettUoaUort-valufe  fietd  of 
ACSE  authentication. 


Authentication-Value  :t* 
^T'-  SJBQUENCE  OF  DirectoryAbstractService .Credentials 

^  I 

This  data  type  is  defined  in  ASN.1  module  DIrectoryAbstractService  of  ISO  9594-3  as  modtfled  tlvough 
tesolution  of  Directory  Defect  Report  No.  9594/058.  The  semantics  of  all  fields  are  a$  speGified;tec^  1 
6»t.2.1  of  ISO  9594-a  \ 


Tte  Autf>enttca^n-Va)ue  Is  defined  as  a 
entities  in  the  authentication  value,  it 

SEQUENCE  because  It  Is  permitted  to  pass  credentials  for  multiple 

is  the  responsibility  of  the  application  to  determine  the  specific 

meaning  < 

and  use  of  multiple 

credentials  in 

such  a  case. 

It 

is 

anticipated  that  specific  applications  (e.g*> 

Network  Management)  would  provide 

>  specifications  for  hand!  Ing  multiji^e  credentials  within  thetf  own  cfetises 

of  Part  13  *  OS  Security  Architectura 


TWs  authentlcati<»i  mechanism  may  employ  any  registered  authentlcatfon  algortthm^  however  ft  Is 
recommended  that  the  authentication  algorithims  Identified  In  clause  12.2  be  used, 

iiii^l.t.1.3  options 

For  the  Simj^e  Credernlals  oi^ion  of  Credentials,  die  foitowing  agreerrjents  applyl'  Confc^mliig  I 

implementations  are  not  required  to  employ  the  OPTIONAL  validity  sequence  of  the  SlmpleCredertfiat  data 
element  Receiving  implementations  that  do  not  employ  the  validity  sequence  must  reject  an  authenticatloni 
ys^ue  which  does  contain  this  sequence.  Corrforming  Imj^ementatlons  shall  employ  the  optional  passwonj 
fl^  of  the  SimpleCredential  data  element 

Ncjte  ths*  the  password  nmy  be  hashed  using  one  way  funt^ns  and  die  other  validity  fields.  Password  Is  3 

iSfither  deartext,  or  Prolectedl  or  PfOtected2  per  ISO  9594-8  (Directory  Authentication  Frameworl<).  ^ 

8s1 . 1 ,2        External  Authentication  Mechanisms 


Brternalfy  d^ned  authentication  exchanges  may  employ  the  external  [2]  option  of  the  authentication-value 
fj^  of  ACSE  authentication.  In  this  case  it  is  recommended  that  the  mechanism-name  be  omitted,  with  th6 
particiiar  mechanism  !n  use  being  implied  by  the  abstract  syntax  identilied  In  the  extemal  construct  j 
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$.1 . 1  «2. 1  K«ti€^o«i  Version  5 

Qm  instance  of  an  external  authentication  mechanism  is  the  Kerberos  mechanism  defined  In  RFC  [TBD]: 
TheK^^b^<»5  ^peC^liCfitttoll  aligned  the::J^^  abstract  syntax  suitable  for  use  in 

ihlss*ayj 

MM 

Piihcomli^ 


9     Message  Handling  System  (MHS)  Security 


10  Directory  Services  Security 


I   1 1    Network  Management  Security 


This  clause  (KJtiines  an 

approach  to  providing  security  services  for  OSI 1 

Metwoii<  Management.  ThegdaJs 

of  this  approach  are  to 

pr<yrfide  seCajrity  in  a  manner  that  is  simple  and  s 

traight-forward 

to  implement,  arKj 

to  avoid  any  unnecessary  computaSonal  and  managerial  overt^iead. 

The  approach  also  takes  into 

OOn^eraticKi  the  r?eed  fordlfferer^fevelsof  security  services  within  different  rietworl<  management  domains, 

and  the  near  tenu  requirement  for  interopefabllity  of  n^oi1<  management  entities  over  disparate  network 

!  ^ypes. 

'i 

1 

i  111  Threats 


i: ' 

puipose  of  discussion,  thread  are 

dMded  into  two  categories:  primary 

and  secondary  threats. 

Primary 

threats 

are 

HiQse  considered 

to 

be  applicable  to  the  full  range 

of 

network 

management 

fimplementagonSi  while  secondary  treats  are 

considered  to  be  appilc^e  to  the  more  limited  range  of  highly 

secure  Im^emenjtattoRSi 
il  The  primary  threats  to  be  pr^rtected  against  are  the  fotiowln0; 
I  a)  The  masqueratjing  of  a  manager  or  agent  entity; 

b)  the  fabricattOn  or  rtiodiflcation  of  Common  Management  Infonnation  Protocd  (Cfi/IlP)  data  unitS} 
j  By  countering  primary  iSireats,  dlisruptlon  d  network  management  services  by  the  casual  user  can  b^ 
! 

i  The  secondary  threats  to  be  i^otected  against  are  the  following; 

a)  All  primary  ^resd;s; 
I  b)  Tf^e  disclosure  of  CfvilP  data  units; 

c)  The  replay,  reflection,  reordering*  insertk>n,  or  deletion  of  CMIP  data  units< 
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it. 2    Security  Services 


ll.a.  I     Basic  Security  Services 

The  security  si^vlces  mqulred  to  counster  prlftiary  i^reats  are: 

a)  Peef  entity  aifthentjcatlon; 

b)  Pata  oilgln  au^en^tloii; 

c)  Corviec^nless  liitegrlty^ 

Peer  entity  authentlcato  Is  to  occur  dyrJng  the  establishment  of  an  ai^lcation  i-      '  ^ 

aasoclatiop  is  successfully  establisliecf.  tbe  urelerfyliig  security  mechanism  prwid " 

subsequenSy  used  In  data  origin  au^en^atlon.  Hieretiie  infomiatton  may  be  Indue 

vivay,  transform  the  (Ma  units  of  ^bsequent  exc^emges  so  that  they  ran  be  Identif!  ai  from 

an  authenticated  entity.  Bd^  authenttcation  secuitEy  sendees  are  to  be  provided  at  the  appiicauon  level  of 

tfeeiprotocc^i 

0<»inectionless  Negity  Insures  that  <M9  Units  (aiginating  *rom  an  authwticated  source  are  nc*  modifiable 
without  detection.  When  combined  with  a  strcmg  data  onlgint  authentication  mechanism,  the  ability  to 
taNc^e  ne»^  data  units  also  countered,  C<yi«©ctlonle$d  integrity  may  be  prov4ded  at  either  ^e 
application  level  of  the  protocol  or  within  one  of  the  lower  levels  of  the  protocol  {le.,  transport  or  ntetwori<}< 


;  Services 

The  security  services  required  to  counter  secot^ry  ^eats  are; 

a)  Alt  ba^^c  sectirity  sen/ices  wfth  the^^^  integrity; 

b)  Ccmnectlonless  confidentjaJit)^ 

c)  Connection  integrity  wfth  or  tfl^h<»jt  recovery. 

Both  connectior^ess  cor*8dentlaiity  and  connection  Ink^rity  may  be  provided  at  either  the  application  lev^ 
of  {H'otocof  or  wtthirt  one  of  the  lower  levels  ci  ii^otooc^  The  latter  provision  is  assumed  here.  Enhanced 
security  services  are  not  discussed  furUier  in  this  ncto,  t»it  to  iae  Issued  as  a  requirement  for  the  lower  layer 
protocol  and  service  standards,  and  according  to  lunci^onai  standards  to  be  developed. 
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nXi     feer  Entity  Authentlcatroti 

P^^Erttfty  Aai!h0nlloatio»  w|l  g$$tK9  AC^  authem^tion  m^oKantsm  and  associated  daia  typ^s  a$  d^aTfrr^ 
Iri  clause  6  <^  Ms  part  of  ihe  lAs.  The  specPRc  auther^cafcion  mechanisms  to  be  supported  is  the  simpif 
St«»t9-auth-m$t^ni$m  de^&i  lit  8.l.t.l. 

^jpp(yr);  df  ACSE  authentiDaUcm  Is  cptlonalx 

iiXti     Coiute<^onl6ss  Integrity 

(Refer  to  the  Working  Implementation  Agreements.) 


stable  Implementation 
Agreements  for  Open  Systems 
Interconnection  Protocols: 
Part  14  -  Virtual  Terminal 


1  Output  from  the  September  1991  NIST  Workshop  for 
I  Implementors  of  OSI 


SIG  Chair:  Luke  Lucas,  Control  Data  Corporation 
SIG  Editor:        Luke  Lucas,  Control  Data  Corporation 
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Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Virtual  Terminal  Special  Interest 
Group  (VTSIG)  of  the  National  Institute  of  Standards  and  Technology  (NIST)  Workshop  for  Implementors 
of  Open  Systems  Interconnection  (OSI).  See  Procedures  Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject.  There  is  no  significant  technical  change  from  this  text  as 
previously  given. 

Three  normative  annexes  are  given. 
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0  Introduction 

The  NIST/OSI  Workshop  Virtual  Terminal  (VT)  SIG  is  making  implementation  agreements  for  the  OSI  Basic 
Class  VT  Service  and  Protocol.  ISO  9040  and  ISO  9041. 

These  implementation  agreements  fall  into  the  following  categories: 

Functionality  to  be  implemented,  i.e.,  functional  units,  etc. 

Identification  and  specification  of  VT  profiles  to  be  supported  by  conforming  implementations. 
Agreements  with  regard  to  implementation  issues  not  specified  in  ISO  9040  and  ISO  9041. 
Resolution  of  problems  with  ISO  9040  and  ISO  9041  identified  during  implementation. 
Statement  of  requirements  to  meet  conformance  to  these  agreements. 

1  Scope 

1.1  Phase  la  Agreements 

The  Telnet  profile  is  intended  to  support  the  following  usage: 

a)  a  simple  line  at  a  time  or  character  at  a  time  dialogue,  and 

b)  an  application  level  gateway  supporting  Internet  Telnet  and  ISO  VTP  interoperation. 

;l  The  Transparent  profile  supports  the  exchange  of  uninterpreted  sequences  of  characters.  This  includes 
i!  support  of  VT-users  who  wish  to  control  terminals  directly  through  the  use  of  embedded  control  characters 
I  and  escape  sequences. 

1.2  Phase  lb  Agreements 

The  Forms  profile  is  intended  to  support  forms-based  applications  with  local  entry  and  validation  of  data  by 
the  terminal  system.  This  profile  is  now  aligned  with  the  EWOS  VT  EG  Functional  Standard. 
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1.3  Phase  II  Agreements 

The  X.3  profile  supports  functionality  similar  to  the  CCITT  recommendations  and  could  be  used  to  implement 
an  X.3  to  ISO-VT  gateway. 

See  Working  Agreements  regarding  Pageotpf  FItIsmI  11  profiles. 

1 .4  Status 

1.4.1  Status  of  phase  la 

I 

Phase  la  of  the  VT  Agreements  was  stabilized  May  5,  1988.  This  phase  covers  the  Telnet  and  Transparent 
profiles.  No  future  enhancements  will  be  made  to  this  phase.  ' 

1.4.2  Status  Of  phase  lb 

Phase  lb  of  the  VT  Agreements  was  first  stabilized  December  16, 1988.  This  phase  covers  the  Forms  profile. 
Alignment  with  EWOS  required  substantial  modifications  which  were  ratified  September  15,  1989. 

1.4.3  Status  Of  phase  II 

Phase  II  is  still  in  progress  and  includes  the  remaining  profile  work  for  Scroll,  Page  (S-mode)  and  Pago  (A 
mod«)Oeneralized  Telnet  profiles. 

The  X.3  profile  of  phase  II  was  stabilized  December  15,  1989. 

I 
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2     Normative  References 

ISO  9040:t99Q,  Information  ProcoGeing  SyGtomG^hmtogy  -  Open  Systems  Interconnection 

-  Virtual  Terminal  Service — Basic  Class  Service. 

ISO  904141*1990,  Information  Proooooing  Syotcmotechnofogy  -  Open  Systems  Interconnection 

-  Virtual  Terminal  Protocol  Basic  Class  Protocol  -  Part  I:  Sp^tlk^tim. 

^^i^^i^^^Mormatton  iechnofogy  ♦  Open  Systems  fnterconnectkm 
^  Pfocedtjres  for  the  Operation  of  OSt  Registration  Aud)0titi6$ 
'  Part  4:  Regist^  of  VTE  Prof  lies. 

\SQ^^&34S,  fr^ormatiorj  technology  '  0pm  Systems  fntercormecffm 

-  Procedures  for  the  Operation  of  0$l  Registration  Aattiodties 
'  Part  5.'  Register  of  VT  Control  Object  Definitions, 
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3  Status 

This  version  of  the  agreements  was  completed  in  December  1990. 

4  Errata 

Editor's  Note  -  'Defect  Report*  material  may  be  included  here,  including  versions  of  implementor  agreements 
to  which  it  applies. 


Table  1  -  Technical  Errata 


06/90-1 

Forms  Profile.    The  "FEICO  Update  Syntax"  ASN.l  connnent  which 
follows  the  definition  of  the  PriValue  type  was  corrected  to 
support  multi-octet  repertoires. 

06/90-2 

Forms  Profile.     The  descriptive  text  for  the  Field  Entry 
Instruction  Violation  FEE  was  corrected  to  indicate  that  both 
an  entry-control  index  and  a  FEPR  index  are  required  to 
identify  the  FEPR  concerned. 

06/90-3 

Forms  Profile.     The  descriptive  text  and  update  syntax  for  the 
Violation  FEC  were  corrected  to  indicate  that  both  a  FEICO- 
name  and  an  index  are  required  to  identify  a  FEIR. 

06/90-4 

Forms  Profile.    The  update  syntax  for  the  writeString  FER  was 
corrected  to  align  with  the  descriptive  text  for  this  FER. 

06/90-5 

Forms  Profile.    The  descriptive  text  for  the  repertoire 
assignment  profile  argument  was  corrected  to  properly  identify 
the  default  value  as  the  GL  set  ISO  2375  Reg.  No.  6  (ASCII). 

06/90-6 

Forms  Profile.    The  concept  of  a  "current  keystroke"  was 
inserted  into  the  definition  of  the  FEICO  to  remove  aunbiguity 
in  the  use  of  the  ST  and  UT  COs .     Various  FEEs,  FECs  and  FERs 
were  redefined. 
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Table  2  -  Alignment  Errata 


06/90-7 

Forms  Profile.     A  definitive  note  was  added  to  define  how  the 
host  is  notified  of  the  current  entry  location  when  data  entry 
terminates  and  the  VTE-parauneter  access-outside-f ields  has  the 
value  "allowed." 

06/90-8 

Forms  Profile.     Three  font-assignment  profile  arguments  were 
added  to  accomodate  INTAP  requirements. 

09/90-1 

Forms  Profile.     The  emphasis  subattribute  "h"  was  added  with 
values  "F"   (Frcuned)  and  "C"  (Encircled). 

09/90-2 

Telnet  Profile.     Four  editorial  comments  were  incorporated  to 
align  with  the  corresponding  EWOS  Functional  Standard. 

Table  3  -  Editorial  Errata 


06/90-9 

Forms  Profile.     Two  definitive  notes  were  added  to  clarify  the 
secondary  attributes  comparison  mechanisms  for  the  FEIs  and 
FECs  that  test  equality  of  characters. 

06/90-10 

Forms  Profile.     A  definitive  note  was  added  to  clarify  the 
effect  of  associating  multiple  Character-oriented  FEIs  of  the 
same  type  with  the  Seune  field. 

06/90-11 

Forms  Profile.     An  introductory  paragraph  in  the  section  "Field 
Entry  Condition  Definitions"  was  rewritten  for  clarification. 

06/90-12 

Forms  Profile.     The  descriptive  text  for  the  Write  String  field 
entry  reaction  was  modified  to  indicate  precisely  how  and  where 
the  associated  string  is  to  be  written. 

09/90-3 

X3  Profile.    The  reference  to  COs  P3  and  P4  contained  in 
comments  relating  to  DEVICE-1  were  corrected  to  reference 
elements  3  and  4  of  the  PAD  CO. 

12/90-1 

X3  Profile.  Changes  were  made  to  correct  editorial  errors 
discovered  during  the  progression  of  the  EWOS  X3  Profile 
Functional  Standard. 

09/91-1 

Scope ,  S tatus,  and  Re f e c ences' '  c laoaes ' 7\i^W' 'tipS* t » 
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5  Conformance 

Conformant  VT  implementations  are  required  to  support  the  ISO  9041  Clause  13  requirements  plus  the 
additional  conformance  requirements  identified  below. 

Table  4  shows  conformance  status  for  VT  facilities  which  are  optional  in  the  ISO  VT  standard.  The  terms  used 
in  the  figure  are  defined  as  indicated  below: 
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-  "Mandatory"  indicates  tliat  the  facility  must  be  provided  by  all  innplementations  which 
conform  to  these  agreements. 

-  "Optional"  indicates  that  the  VT  facility  is  not  required  to  meet  minimum  conformance 
requirements  but  has  been  identified  as  providing  additional  useful  capabilities. 

-  "Profile  Dependent"  indicates  that  the  requirement  for  the  facility,  if  any,  is  included  in 
the  profile  definitions. 

-  "Not  Addressed"  indicates  that  the  VT  facility  is  outside  the  scope  of  these  agreements. 


Table  4  -  Conformance  Status  for  VT  Facilities 


Conformance  Status 

Mandatory 

Optional 

Profile 
Dependent 

Not 
Addressed 

Switch  Profile'^'' 



X 

Multiple  Interaction 
Negotiation^ ' 

X 

Negotiated  Release^ ^ 

X 

Urgent  Data^^ 

X 

Break^) 

X 

Delivery  Control^ ^ 

X 

Enhanced  Access  Rules 

X 

Structured  COs^^ 

X 

Blocks^  ^ 

X 

Fields^) 

X 

RIOs^) 

X 

S-mode 

X 

A-mode 

X 

Mode  Switching  Capability 

X 

1)  It  is  not  anticipated  that  new  profiles  will  use  quarantined  delivery 
control . 

2)  Functional  Units. 

For  each  mode  of  operation  (A-mode  and  S-mode)  which  is  implemented,  the  default  profile  for  that  mode 
as  defined  in  ISO  9040  must  be  supported.  Implementations  that  support  A-mode  must  support  the  A-mode 
default  profile  and  at  least  one  additional  Workshop  approved  A-mode  profile.  The  Transparent  profile  does 
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not  count  as  an  additional  A-mode  profile.  Implennentations  that  support  S-mode  must  support  the  S-mode 
default  profile  and  at  least  one  additional  Workshop  approved  S-mode  profile. 

For  each  profile  implemented,  VIE  parameter  ranges  or  values  specified  in  the  Workshop-agreed  profile  and 
associated  notes  must  be  supported. 


6  Protocol 

6.1  Protocol  Elements 

All  protocol  elements  required  by  the  ISO  9040  VT  kernel  and  Break  functional  units  are  selected. 

All  protocol  elements  required  by  the  Switch  Profile  functional  unit  are  selected  if  this  functional  unit  is  used. 
See  Table  4. 

All  protocol  elements  required  by  the  Urgent  Data  functional  unit  are  selected  if  this  functional  unit  is  used. 
See  Table  4. 

6.2  Mapping  of  Protocol  Elements 

Mapping  of  protocol  elements  on  to  ACSE  or  Presentation  Services  is  as  defined  in  ISO  9041. 

6.3  Protocol  Data  Unit  Structure 

Protocol  data  unit  structure  is  as  defined  in  ISO  9041. 


7     OIW  Registered  Control  Objects 

The  following  Control  Objects  are  used  by  more  than  one  profile.  Some  of  the  CO  parameters  are  left  with 
undefined  values  that  must  be  assigned  by  the  profile  in  which  the  Control  Object  is  used. 


7.1      Sequenced  Application  (SA) 

This  is  a  Control  object  used  to  convey  signals  from  the  application  to  the  terminal  in  sequence  with  other 
updates. 
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7.1.1  Entry  Number 

To  be  supplied  by  Registration  Authority. 

7.1.2  Name  of  Sponsoring  Body 

OSI  Implementors'  Wori<shop  (OIW),  VTSIG. 

7.1.3  Date 


The  date  of  submission  of  this  proposal  is  Septemtjer  15,  1989. 


I    7.1.4  Identifier 

j     oiw-vt-co-misc-sa  OBJECT  IDENTIFIER  ::=  {oiw-vt-co-misc  sa(0)} 

7.1.5  Descriptor  Value 

"OIW  VT  CO  for  conveying  Sequenced  Application  Signals" 

7.1.6  CO  Parameters 

CO-structure  1 

CO-priority  "normal" 

CO-category  "symbolic" 

CO-size  1 1 

J    7.1.7       CO  Values  and  Semantics 


Table  5  lists  the  allowed  symbolic  values  together  with  the  integers  used  to  reference  these  values  in  the 
ASN.1  update  syntax  of  ISO  9041: 
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Table  5  -  SA/UA  CO  values  and  semantics 


SymDoiic  value 

Integer  Value 

audible_alarm 

0 

newlines_enabled 

1 

newlines  disabled 

2 

restore 

3 

visuax  ai.arin 

A 

keypad_enabled 

5 

keypad_disabled 

6 

keyboard_locked 

7 

keyboard_unlocked 

8 

de V  i  ce_d  i  s  connect 

9 

break_signal 

10 

The  semantics  of  each  value  must  be  specified  in  the  VTE  profile  which  references  this  CO. 

7.1.8  Additional  information 

None. 

7.1.9  Usage 

Defined  in  profile. 

7.2      Unsequenced  Application  (UA) 

This  is  a  Control  object  used  to  convey  urgent  signals  from  the  application  to  the  terminal. 

7.2.1        Entry  Number 

To  be  supplied  by  Registration  Authority. 
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7.2.2  Name  of  Sponsoring  Body 

OSI  Implementors'  Workshop  (OIW),  VTSIG. 

7.2.3  Date 

The  date  of  submission  of  this  proposal  is  September  15,  1989. 

7.2.4  Identifier 

oiw-vt-co-misc-ua  OBJECT  IDENTIFIER::  =  {oiw-vt-co-misc  ua(1)} 

7.2.5  Descriptor  Value 

"OIW  VT  CO  for  conveying  Unsequenced  Application  Signals" 

7.2.6  CO  Parameters 

CO-structure  1 

CO-priority  "urgent" 

CO-category  "symbolic" 

CO-size  1 1 


7.2.7 


CO  Values  and  Semantics 


Same  as  in  SA. 


7.2.8 


Additional  Information 


None. 


7.2.9 


Usage 


Defined  in  profile. 
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7.3      Sequenced  Terminal  (ST) 

A  keyboard  can  generate  many  signals  that  may  be  given  special  meaning  to  the  application.  This  CO  is 
general  enough  to  convey  any  keyboard  event. 


OSI  Implementors  Workshop  (OIW),  VTSIG. 

7.3.3  Date 

The  date  of  submission  of  this  proposal  is  September  15,  1989. 

7.3.4  Identifier 

oiw-vt-co-misc-st  OBJECT  IDENTIFIER  ::=  {oiw-vt-co-misc  st(2)} 

7.3.5  Descriptor  Value 

"OIW  VT  CO  for  conveying  Sequenced  Terminal  Signals" 

7.3.6  CO  Parameters 

CO-structure  1 
CO-priority  "normal" 
CO-category  "integer" 
CO-size  65535 

7.3.7  CO  Values  and  Semantics 

The  values  of  the  CO  are  composite,  with  values  from  Table  6  giving  meaning  to  the  values  in  the  hex  range 
00-FF  when  added  to  them. 


7.3.1 


Entry  Number 


To  be  supplied  by  Registration  Authority. 


7.3.2 


Name  of  Sponsoring  Body 
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hex  value 

meaning 

100 

special  key  -  labeled-'-^ 

200 

function  key  depressed 

400 

control  key  depressed 

800 

shift  key  depressed 

1000 

alt  key  depressed 

1)  possible  special  key  values  are 
as  defined  by  the  STCO  ASN.l  module. 

The  special  key  and  the  function  key  are  mutually  exclusive.  If  neither  the  function  keys  nor  the  special  keys 
are  pressed,  then  the  value  in  the  hex  range  00-FF  will  be  that  of  the  normal,  unshifted  code  combination 
generated  by  the  alpha-numeric  key.  Values  in  the  hex  range  00-FF  are  not  valid  values  for  the  data  element 
of  this  Control  Object. 

The  control,  shift,  and  alt  keys  may  appear  in  any  combination  with  the  special  or  function  keys. 

The  shift  key  must  occur  in  combination  with  at  least  one  of  the  other  keys  in  the  above  table  to  cause  the 
value  to  fall  outside  the  repertoire  of  the  display  object. 

When  the  special  key  is  depressed,  the  value  of  the  CO  content  will  be  as  given  in  the  ASN.1  module  below 
for  the  value  in  the  hex  range  of  00-FF.  Othenwise,  the  value  will  be  defined  to  be  the  IA5  value  associated 
with  the  key. 
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Key  ::=  INTEGER  { 


break  (0), 

tab  (3), 

carReturn  (6), 

escape  (9), 

multiply  (12), 

rightArrow  (15), 

insert  (18), 

deleteLine  (21), 

PageUp  (24), 

pa2  (27), 

status  Process  (30), 

abortOutput  (33), 

print  (36), 

endOf  Record  (39), 


bell 

backTab 

cancel 

plus 

divide 

up  Arrow 

delete 

home 

PageDown 

pa3 

interruptProcess 
formFeed 
refresh 
endOfFile 


(1). 
(4), 
(7), 
(10) 
(13) 
(16) 
(19) 
(22) 
(25) 
(28) 

(31) 
(34) 
(37) 
(40) 


backspace 

lineFeed 

substitute 

minus 

leftArrow 

downArrow 

insertLine 

end 

pa1 

help 

terminateProcess 
clear 

systemRequest 
suspendProcess 


(2), 
(5). 
(8), 

(11) 
(14) 

(17) 
(20) 
(23) 
(26) 
(29) 
(32) 
(35) 
(38) 
(41) 


--  Names  for  combination  keystrokes  are  formed  by  converting  the 
--  initial  letter  to  upper  case  and  prefixing  with  'Ctrl',  'shift'  or 
--  'alt',  which  adds  1024,  2048  or  4096  respectively  to  the  value. 
--  These  prefixes  may  be  used  in  combination  with  one  another  by  a 

-  repetition  of  this  conversion  process,  provided  that  they  appear 

-  from  left  to  right  in  the  order  'Ctrl',  'shift',  'alf.  ASN.1 

-  formally  does  not  allow  such  descriptive  additions  but  it  would  be 

-  very  lengthy  to  write  them  all  in  full  --  } 

END   *(STCO  DEFINITIONS)* 
VTE  profile  definitions  may  refer  to  this  module  for  convenience  in  describing  semantics. 


7.3.8       Additional  Information 

None. 


7.3.9  Usage 

Defined  in  profile. 
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7.4      Unsequenced  Terminal  (UT) 

Keyboard  events  may  need  to  be  conveyed  urgently,  out  of  sequence  with  nornrial  updates.  This  CO  is  used 
to  signal  such  events  from  the  terminal  to  the  application. 

7.4.1  Entry  Number 

To  be  supplied  by  the  Registration  Authority. 

7.4.2  Name  of  Sponsoring  Body 

OSI  Implementors  Workshop  (OIW),  VTSIG 

7.4.3  Date 

The  date  of  submission  of  this  proposal  is  September  15,  1989. 

7.4.4  Identifier 

1      olw-vt-co-mlsc-ut  OBJECT  IDENTIFIER  ::=  {olw-vt-co-misc  ut(3)} 

7.4.5  Descriptor  Value 

"OIW  VT  CO  for  conveying  Unsequenced  Terminal  Signals" 

7.4.6  CO  Parameters 

j  CO-structure  1 

!  CO-priority  "urgent" 

i  CO-category  "Integer" 

'  CO-sIze  65535 

i     7.4.7       CO  Values  and  Semantics 

I      Same  as  in  ST. 
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7.4.8 


Additional  Information 


None. 


7.4.9 


Usage 


Defined  in  profile. 
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OIW  Defined  Profiles 


These  profiles  are  defined  using  tfie  conventions  specified  in  Annex  A  of  ISO  9040. 

8.1      Telnet  Profile 

OIW  VTE-Profile  TelneM988  (r1,  r2) 

8.1.1  Introduction 

This  profile  provides  support  for  TELNET-like  operation  for  users  of  the  ISO  Virtual  Terminal  Service.  It  is 
based  on  the  IS  version  of  ISO  9040  and  ISO  9041 . 

8.1.2  Association  Requirements 

8.1.2.1  Functional  Units 

The  Urgent  Data  Functional  Unit  is  optional,  but  should  be  used  whenever  available. 

8.1.2.2  Mode 

This  is  an  A-mode  profile. 

8.1.3  Profile  Body 

Display-objects  =  *(double  occurrence)* 


{ 
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"unbounded," 
"no  constraint," 
no, 

profile-argument-rl 


"unbounded," 
"higher  only," 
"no," 
1 


{ 

display-object-name  =  D,  *{DISPLAY) 
do-access  =  "WACA," 

dimensions  =  "two," 

x-dimension  = 

{ 

x-bound 
x-addressing 
x-absolute 
x-window 

}. 

y-dimension  = 
{ 

y-bound 
y-addressing 
y-absolute 
y-window 
}, 

erasure-capability  =  "yes," 
repertoire-capability  =  2, 
repertoire-assignment  =  profile-argument-r2, 
repertoire-assignment  =  <ESC>  2/5  2/15  4/2 
}. 
{ 

display-object-name  =  K,  *(KEYBOARD)* 
do-access  =  "WACI," 

dimensions  =  "two," 

x-dimension  = 

{ 

x-bound 
x-addressing 
x-absolute 
x-window 

}. 

y-dimension  = 
{ 

y-bound 
y-addressing 
y-absolute 
y-window 

}. 

erasure-capability  =  "yes," 
repertoire-capability  =  2, 


"unbounded," 
"no  constraint," 
no, 

profile-argument-r1 


"unbounded," 
"higher  only," 
"no," 
1 
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repertoire-assignment  =  profiie-argument-r2, 
repertoire-assignment  =  <ESC>  2/5  2/15  4/2 
} 


Control-objects  =  *{multiple  occurrence)* 
{ 

{  *(SYNCHRONIZE)* 

co-name  =  SY, 

co-access  =  "NSAC," 

CO-category  =  "symbolic," 

CO-size  =  1, 

CO-priority  =  "urgent" 

}, 

{  *(DISPU\Y-SIGNAL)* 

co-name  =  Dl, 

co-access  =  "WACA," 

CO-category  =  "boolean," 

CO-size  =  5, 

CO-priority  =  "normal," 

co-trigger  =  "selected" 

}. 

{  *{KEYBOARD-SIGNAL)* 

co-name  =  KB, 

co-access  =  "WACI," 

CO-category  =  "boolean," 

CO-size  =  5, 

CO-priority  =  "normal," 

CO-trigger  =  "selected" 

{  *(NEGOTIATION  BY  INITIATOR)* 

CO-name  =  Nl, 

co-access  =  "WACI," 

CO-category  =  "boolean," 

CO-size  =  4, 

CO-priority  =  "normal," 

CO-trigger  =  "selected" 

{  *(NEGOTIATION  BY  ACCEPTOR)* 

CO-name  =  NA, 

co-access  =  "WACA," 

CO-category  =  "boolean," 

CO-size  =  4, 


December  1990  (Stable) 
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}. 


CO-priority  =  "normal," 

co-trigger  =  "selected" 

}. 

{  *  (GO-AHEAD)* 

CO-name  =  GA, 

co-access  =  "NSAC," 

CO-category  =  "boolean," 

co-size  =  1, 

CO-priority  =  "normal," 

CO-trigger  =  "selected" 

} 


Device-objects  =  *  (double  occurrence)* 
{ 

{ 

device-name  =  DISPLAY-DEVICE, 
device-display-object  =  D, 
device-default-CO-initial-value  =  1."true,"*("on")* 
device-minimum-X-array-length  =  1,*(no  constraint)* 
device-minimum-Y-array-length  =  1,* (no  constraint)* 
device-control-object  =  SY, 
device-control-object  =  NA, 
device-control-object  =  Dl, 
device-control-object  =  GA, 

*(SYNC,NEGOTIATE-ACCEPTOR, DISPLAY-SIGNAL, 
GO-AHEAD)* 
device-default-CO-access  =  "WACA," 
device-default-CO-priority  =  "normal" 

*(other  device  object  parameters  assume  corresponding  DO  values)" 

}. 
{ 

device-name  =  KEYBOARD-DEVICE, 
device-display-object  =  K, 
device-default-CO-access  =  "WACI," 
device-default-CO-priority  =  "normal," 
device-default-CO-initial-value  =  1."true,"*("on")* 
device-minimum-X-array-length  =  1,* (no  constraint)* 
device-minimum-Y-array-length  =  1,*(no  constraint)* 
device-control-object  =  SY, 
device-control-object  =  Nl, 
device-control-object  =  KB, 
device-control-object  =  GA, 
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*(SYNC,NEGOTIATE-INITIATOR,KEYBOARD-SIGNAU 
GO-AHEAD)* 

*(other  device  object  parameters  assume  corresponding  DO  values)* 
} 

}. 

Type  of  delivery  control  =  "simple-delivery-controL" 


8.1.4       Profile  Arguments 


r1  -  is  used  to  represent  the  line  length  as  the  vaiue  of  VIE  parameter  x-window  for  both  display  objects. 
This  argument  is  mandatory  and  takes  a  nonnegative  integer  value.  This  argument  is  identified  by 
the  identifier  for  x-window  for  display  object  D. 

r2  -  is  used  to  designate  the  default  repertoire  for  both  display  objects.  This  argument  is  optional,  if  not 
present  the  full  US  ASCII  set  is  the  default.  This  argument  is  identified  by  the  identifier  for  repertoire 
assignment  for  the  display  object  D. 

8.1.5       Profile  dependent  Control  Object  information 

This  profile  does  not  reference  any  Control  Objects  which  are  not  defined  within  this  profile. 


8.1.6 


Profile  Notes 


8.1=6,1 


Definitive  Notes 


1. 


Booleans  in  the  KB  and  Dl  control  objects  are  used  in  this  profile  to  correspond  to  TELNET 
commands  as  follows: 


Table  7  -  KB/Di  CO  value  definitions 


Control  Object 


Booleein 


TELNET 
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The  equivalent  of  a  TELNET  command  is  achieved  by  selecting  the  boolean  that 
corresponds  to  the  desired  TELNET  command.  Selecting  a  boolean  in  the  Dl  or 
KB  control  object  means  setting  the  value  of  the  desired  boolean  to  "true."  The 
usage  of  the  mask  element  of  the  boolean  update  is  as  specified  in  ISO  9041. 

2.  The  equivalent  of  a  TELNET  SYNCH  command  Is  achieved  by  updating  the  SY  control  object  with 
the  single  symbolic  value  of  "SYNCH"  (which  is  mapped  onto  the  integer  value  1),  and  immediately 
updating  the  Dl  (or  KB)  control  object  selecting  the  DM  boolean.  IP,  AO,  AYT,  or  BREAK 
commands  may  be  accompanied  by  a  SYNCH  command  by  updating  the  SY  control  object  and 
then  updating  the  Dl  or  KB  control  object  selecting  both  the  DM  and  the  other  desired  boolean. 
When  an  update  to  the  SY  control  object  is  received  subsequent  display  object  updates  are 
discarded  until  an  update  to  the  Dl  or  KB  control  object  is  received  selecting  the  DM  bit.  If  a  'VT- 
BREAK  is  received  after  an  SY  CO  update  has  been  received  and  prior  to  the  corresponding  Dl  or 
KB  CO  update  selecting  the  DM  boolean,  the  discarding  of  updates  is  terminated.  This  is  necessary 
because  the  VT-BREAK  may  have  caused  the  Dl  or  KB  CO  update  to  be  purged. 

3.  The  Nl  and  NA  control  objects  are  used  to  emulate  the  TELNET  option  negotiation  facility.  The 
facility  is  symmetric,  allowing  either  party  to  open  negotiation  for  a  change  of  mode,  and  every 
negotiation  must  be  accepted  or  rejected  by  the  opposite  party.  The  rules  for  negotiation  for  each 
of  the  option  controls  are  as  stated  in  RFC  854  and  as  given  below. 

a.  Only  open  negotiation  for  a  change  from  the  current  state. 

b.  Only  acknowledge  negotiation  for  a  change  from  the  current  state. 

c.  Do  not  send  any  object  updates  with  a  negotiation  outstanding  except  an  update  to  the 
Nl  (or  NA)  control  object  to  acknowledge  negotiation. 

For  full  symmetry,  both  the  Nl  and  NA  control  objects  have  the  same  value  definition  and  consist 
of  4  booleans  with  the  semantics  given  in  Table  8. 


Table  8  -  Ni/NA  CO  value  definition 


BIT 

  .... 

Option 

Value  J 

1 

Remote  Echo 

"false"  Echo  is  Local; 
"true"  Echo  is  remote 

2 

Suppress  Go  Ahead 

"false"  GO  Ahead; 

"true"  Suppress  Go  Ahead 

3 

Binary  WACA 

"true"  use  binary  WACA; 

"false"  use  default  or  negotiated 

repertoire  for  WACA  display  object 

4 

Binary  WACI 

"true"  use  binary  WACI; 

"false"  use  default  or  negotiated 

repertoire  for  WACI  display  object 
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Booleans  3  and  4  control  the  use  of  the  Transparent  character  set  for  the  D  and  K  display  objects 
respectively.  A  value  of  '1rue"  indicates  the  use  of  the  binary  repertoire;  "false"  indicates  the  use 
of  the  negotiated  repertoire.  When  a  party  wants  to  change  a  repertoire  assignment,  it  must 
complete  a  successful  TELNET  negotiation  to  change  the  option  control.  Then  the  party  with  the 
access  rights  to  the  display  object  in  question  is  required  to  perform  the  corresponding  secondary 
attribute  modal  update. 

4.  The  TELNET  EC  (erase  character)  command  will  be  mapped  to  a  pointer  relative  (x:  =  x-1)  update 
and  an  erase  current  update.  The  TELNET  EL  (erase  line)  command  will  be  mapped  to  an  erase- 
full-x-arrav  update  (an  erase  operation  where  the  extent  is  defined  as  <"start-x,"(Yc,Xc-l)>  and  a 
pointer  update  to  set  x  =  1 .  These  X  dimension  updates  are  the  only  times  when  backward  explicit 
addressing  is  permitted. 

5.  The  X  address  of  the  pointer  can  be  moved  forward  only  by  implicit  pointer  addressing.  Addressing 
of  the  Y  dimension  is  limited  to  the  next  X-array  update  operation. 

6.  The  VT  next  X-arrav  update  operation  wil!  be  sent  in  place  of  the  TELNET  NVT  "CR.LF"  sequence. 

7.  While  the  "binary"  repertoire  is  being  used  no  mapping  to  pointer  addressing  or  erase  operations 
will  be  done. 

8.  The  repertoire  designation  "7-bit  ASCI!  (GO  +  CO)"  refers  to  the  repertoire  invoked  by  ISO  2022 
defined  character  set  designating  escape  sequences  <ESC>  2/8  4/2,  "void,"  <ESC>  2/1  4/0.  The 
repertoire  designation  "7-bit  ASCII  (GO  only)"  refers  to  the  repertoire  invoked  by  the  ISO  2022 
defined  character  set  designating  escape  sequence  <ESC>  2/8  4/2.  The  designation  "binary" 

;    refers  to  the  "Virtual  Terminal  Service  Transparent  Set"  registered  in  the  International  Register  under 
ISO  2375  register  value  125  and  invoked  by  the  escape  sequence  <ESC>  2/5  2/15  4/2. 

9.  No  termination  event  list  is  specified  so  that  data  buffering  and  delivery  can  be  controlled  according 
to  context.  If  local  echoing  is  enabled,  the  local  newline  or  enter  event  shall  trigger  a  VT-DEUVER 
request.  With  remote  echo  a  timeout  or  buffer  length  may  be  used  to  trigger  a  VT-DELIVER  request. 
This  buffer  length  may  be  1 . 


8.1 .6.2        Informative  Notes 

1 .  Users  of  this  profile  should  refer  to  the  TELNET  specification  (MIL-STD-1 782)  and  RFCs  854  and  855 
for  semantics  of  the  TELNET  commands.  These  documents  can  be  obtained  by  contacting  SRI 
International,  DDN  Network  Information  Center,  333  Ravenswood  Ave.,  Menio  Park,  CA  94025,  (415) 
859-3695. 

2.  An  update  to  the  GA  control  object  is  equivalent  to  the  TELNET  Go  Ahead  command. 

3.  If  the  "go  ahead"  facility  has  been  negotiated  then  follovk/ing  a  VT-BREAK,  only  the  association 
acceptor  has  the  right  to  send  data.  In  the  event  of  VT-BREAK  the  echo  control  objects  are 


20 


PART  14  -  VIRTUAL  TERWIINAL 


December  1990  (Stable) 


reinitialized  to  'lalse,"  meaning  local  echo.  If  remote  echo  is  desired  it  must  be  re-negotiated 
following  VT-BREAK. 

4.  Negotiation  of  TELNET  options  other  than  echo,  transmit  binary,  and  SUPPRESS  GO  AHEAD  is  not 
supported  by  this  profile.  Negotiations  for  these  three  options  can  take  place  at  any  time  during 
a  session. 

8.1.7       Specific  Conformance  Requirements 

The  following  character  sets  are  required: 

-  The  GO  character  set  for  U.S.  7-bit  ASCII  (values  32-126), 

-  The  full  U.S.  7-bit  ASCII  (values  0-127),  and 

-  The  transparent  character  set,  see  Definitive  Note  8  in  clause  8.1.6.1. 
8.2      Transparent  Profile 

OIW  VTE-Profile  Transparent-1988  (r1) 

8.2.1  introduction 

This  profile  is  intended  to  provide  a  transparent  mode  of  operation  which  allows  VT-users  to  exchange 
transparently  uninterpreted  sequences  of  characters  but  with  the  added  benefit  of  delivery  control  to  enable 
the  VT-users  to  determine  when  the  character  sequences  are  to  be  delivered. 

This  profile  may  be  used  when  VT-users  wish  to  control  terminals  directly  through  the  use  of  embedded 
control  characters. 

8.2.2  Association  Requirements 

I 

8.2.2.1         Functional  Units 

No  additional  functional  units  are  required  by  this  profile. 
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This  is  an  A-mode  profile. 


8.2.3       Profile  Body 

Display-objects  *  (double  occurrence)*  = 
{ 

{ 

display-object-name  =  D1, 

do-access  =  "WACA," 

dimensions  =  "one," 

x-dimension  = 

{ 

x-addressing  =  "not-permitted" 

repertoire-assignment  =  profile-argument-r1 

}. 

{ 

display-object-name  =  D2, 

do-access  =  "WACI," 

dimensions  =  "one," 

x-dimension  = 

{ 

x-addressing  =  "not-permitted" 

}. 

repertoire-assignment  =  profile-argument-r1 
} 

type-of-delivery-control  =  "simple-delivery-control." 


8.2.4       Profile  Arguments 

r1  -  is  optional  and  enables  negotiation  of  a  value  for  the  VTE-parameter  repertoire-assignment  for  the 
two  display  objects  (which  always  have  the  same  value  of  repertoire  assignment  when  the  profile 
is  called).  The  default  value  of  this  argument  is  the  "Virtual  Terminal  Transparent  Set"  registered  in 
the  International  Register  under  ISO  2375  register  value  125,  invoked  by  the  escape  sequence 
<ESC>  2/5  2/15  4/2.  This  argument  is  identified  by  the  identifier  for  repertoire-assignment  for 
display  object  D1 . 
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8.2.5       Profile  dependent  Control  Object  Information 


This  profile  does  not  reference  any  Control  Objects. 


8.2.6       Profile  Notes 

1 .  This  profile  is  intended  primarily  for  applications  requiring  a  sinnultaneous  two  way  exchange  of 
sequences  of  uninterpreted  characters.  The  semantics  usually  associated  with  the  display  object 
are  not  used;  for  the  purposes  of  this  profile,  the  primary  attributes  of  the  character-box  graphic 
elements  are  actually  octets  which  are  passed  directly  to  the  real  device.  There  is  no  relationship 
between  the  elements  of  the  X-array  and  the  character  boxes  of  the  real  device;  the  secondary 
attributes  of  the  display  object  are  not  utilized.  The  only  operation  on  the  display  object  which  must 
be  supported  is  the  text  operation.  An  alternative  repertoire  may  be  selected. 


8.2.7       Specific  Conformance  Requirements 

Support  for  the  default  (transparent)  character  set  is  required.  It  is  strongly  recommended  that  the  profile 
argument  not  be  used. 


8.3      Forms  Profile 

OIW  VTE-Profile  Forms-1989  (r1,r2,  .  .  .  r28) 


8.3.1  Introduction 

This  S-mode  VTE-profile  is  intended  for  supporting  the  use  of  forms  based,  field  oriented  data  entry 
applications  between  a  terminal  and  a  host  system. 

It  provides  facilities  for: 

-  defining  and  using  screen  forms, 

-  defining  field  validation  and  field  entry  rules,  and 

-  controlling  and  validating  field  entry. 

This  VTE-profile  includes  support  of  an  optional  terminal-end  locally  attached  printer. 
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8.3.2.1         Functional  Units 

The  following  VT  functional  units  are  required  for  operation  with  this  profile: 

-  Enhanced  access-rules, 

-  Structured  COs, 

-  Fields,  and 

-  Reference  Information  Objects 

The  following  VT  functional  units  are  optional  for  operation  with  this  profile: 

-  Urgent  Data 


8.3.2.2  Mode 

This  is  an  S-mode  profile. 


8.3.3       Profile  Body 

Display-objects  *  (single  occurrence)*  = 

{ 

display-object-name  =  A, 
DO-access  =  "WAVAR," 

dimensions  =  "three," 

x-dimension  = 

{ 

x-bound 
x-addressing 
x-absolute 
x-window 

y-dimension  = 
{ 

y-bound 
y-addressing 


profile-argument-r1, 
"no  constraint," 
"yes," 
x-bound 


profile-argument-r2, 
"no  constraint," 
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y-absolute 
y-window 

}, 


=  "yes," 
=  y-bound 


z-dimension  = 


{ 

z-bound 

z-addressing 

z-absolute 

z-window 

}. 


=  "unbounded," 
=  "no  constraint," 
=  no, 

=  profile-argument-r3 


erasure-capability  =  "yes," 
repertoire-capability  *  (implicitly  defined  by  r4)*, 
repertoire-assignment  =  profile-argument-r4, 

font-capability  *  (implicitly  defined  by  r5)*, 
font-assignment  =  profile-argument-r5, 
DO-emphasis  =  profile-argument-r6, 

foreground-colour-capability  =  profile-argument-r7, 
foreground-colour-assignment  =  profile-argument-r8, 
background-colour-capability  =  profile-argument-r7, 
background-colour-assignment  =  profile-argument-r9, 

block-definition-capability  =  "no," 
field-definition-capability  =  "yes," 
max-fields  =  "unbounded," 
max-field-elements  =  profile-argument-r10, 
access-outside-fields  =  profile-argument-r1 1 


Control-objects  = 

{ 

{  *(Field  Definition  CO)* 
CO-name 
CO-type-identifier 
CO-structure 


=  FD, 

=  vt-b-sco-fdco, 

=  "non-parametric," 

=  "WAVAR"  +  profile-argument-r12, 

=  "normal," 

=  "not-selected" 


CO-access 
CO-priority 
CO-trigger 
}. 


{  *(Field  Entry  Instructions  CO)* 
CO-name  =  El, 
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CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

co-trigger 

}. 

{  *(Field  Entry  Pilot  CO)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

}. 

{  *(Context  CO)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 


=  "mandatory-feico," 

=  "non-parametric," 

=  "WAVAR"  +  profile-argument-r12, 

=  "normal," 

=  "not-selected" 


=  EP, 

=  "mandatory-fepco," 

=  "non-parametric," 

=  "WAVAR"  -I-  profile-argument-r12, 

=  "normal," 

=  "not-selected" 


=  CC, 

=  vt-b-sco-cco, 
=  6, 

=  "WAVAR," 
=  "normal," 
=  "not-selected" 


{  *{Transmission  Policy  CO)' 
CO-name 
CO-type-identifier 
CO-structure 
CO-access 
CO-priority 
CO-trigger 
CO-category 
co-size 
}. 

{  *(Multiple  occurrence  of  optional  COs.  All  unspecified  VTE-parameters  of  such  CDs 
are  determined  by  their  CO-type-identifier  through  their  registered  definition.  They  may 
include  parameters  specified  to  be  additional  profile  arguments,  which  should  follow  the 
appropriate  CO-type-identifier  argument  value)* 


TP, 

vt-b-sco-tpco, 
1, 

"WAVAR"  +  profile-argument-r12, 

"normal," 

"not-selected," 

"boolean." 

4 


CO-name 
CO-type-identifier 


=  profile-argument-r13, 
=  profile-argument-r14 


26 


PART  14  -  VIRTUAL  TERMINAL 


December  1990  (Stable) 


{  *{Form  Waiting  Time  CO)* 
CO-name 
CO-type-identifier 
CO-structure 
CO-access 
CO-priority 
CO-trigger 
CO-category 
co-size 


=  WT, 

=  "waiting-time," 
=  1, 

=  "WAVAR," 
=  "normal," 
=  "not-selected," 
=  "integer," 
=  65535 


*(The  initial  value  for  WT  is  zero,  implying  that  a  Form  Waiting  Time  is  not  to  be  used.)* 

*(The  following  four  COs,  (SA,  UA,  ST,  and  UT),  are  registered  with  the  OIW  registration  authority 
and  are  referenced  by  this  profile.)* 


{  *(As  defined  in  clause  7)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

CO-category 

CO-size 

}, 

{  *{As  defined  in  clause  7)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

CO-category 

CO-size 

}, 

{  *(As  defined  in  clause  7)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 


SA, 

oiw-vt-co-misc-sa, 
1, 

"WAVAR"  +  profile-argument-r12, 

"normal," 

"not-selected," 

"symbolic," 

11 


UA, 

oiw-vt-co-misc-ua, 
1, 

profile-argument-rl  2, 

"urgent," 

"not-selected," 

"symbolic," 

11 


ST, 

oiw-vt-co-misc-st, 
1, 

"WAVAR"  +  opposite  of  profile-argument-r1 2, 
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CO-priority 

CO-trigger 

CO-category 

CO-size 

}. 

{  *(As  defined  in  clause  7)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

CO-category 

CO-size 


"normal," 
"not-selected," 
"integer," 
65535 


UT, 

oiw-vt-co-misc-ut, 
1. 

opposite  of  profile-argument-r12, 

"urgent," 

"not-selected," 

"integer," 

65535 


Device-objects  *(single  or  double  occurrence)*  = 
{ 

{ 

device-name  =  D, 

device-default-CO-access  =  "WAVAR," 
device-default-CO-priority  =  "normal," 
device-default-CO-trigger  =  "not-selected," 
device-default-CO-initial-value  =  1  ."true," 
device-repertoire-assignment  =  profile-argument-r15, 
device-font-assignment  =  profile-argument-r16, 
device-emphasis  =  profile-argument-r17, 
device-foreground-colour-assignment  =  profile-argument-r1 8, 
device-background-colour-assignment  =  profile-argument-r19, 
device-minimum-X-array-length  =  profile-argument-r20, 
device-minimum-Y-array-length  =  profile-argument-r21, 
device-control-object  =  FD, 
device-control-object  =  CC, 
device-control-object  =  SA, 
device-control-object  =  UA, 
device-control-object  =  ST, 
device-control-object  =  UT, 
device-control-object  =  WT, 
device-control-object  =  TP, 
device-control-object  =  profiie-argument-r22, 
device-display-object  =  A 
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} 


IF  r23  =  "true"  THEN  *(define  printer)* 
{ 


device-name  =  P, 

device-default-CO-access  =  "NSAC," 
device-default-CO-priority  =  "high," 
device-default-CO-trigger  =  "not-selected," 
device-default-CO-initial-value  =  1  ."false," 
device-repertoire-assignment  =  profile-argument-r24, 
device-font-assignment  =  profile-argument-r25, 
device-emphasis  =  profile-argument-r26, 
device-foreground-colour-assignment  =  profile-argument-r27, 
device-background-colour-assignment  =  profile-argument-r28, 
device-minimum-X-array-length  =  profile-argument-r29, 
device-minimum-Y-array-length  =  profile-argument-r30, 
device-control-object  =  FD, 
device-control-object  =  SA, 
device-control-object  =  UA, 
device-control-object  =  profile-argument-r31, 
device-display-object  =  A 


type-of-delivery-control  =  "simple  delivery  control." 


8.3.4       FIXED  Field  Entry  instruction  Definitions  -  non-parametric 


Field  entry  Is  optional.  This  FEI  is  provided  for  completeness  only,  as  a  field  not  linked  to  one  of  the 
Mandatory  field,  Selectable  field  or  Protected  field  FEIs  is  necessarily  optional.  This  FEI  can  never  be 
violated. 


} 


} 


8.3.4.1 


Optional  Field 


8.3.4.2 


Mandatory  Field 
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Field  entry  is  mandatory.  Violation  of  this  FEI  will  occur  if  all  array  elements  of  this  field  are  empty  when 
one  of  the  reactions  FER01  (Transmit  updates)  or  FER02  (Relinquish  WAVAR)  is  initiated.  See  also  the 
specification  of  these  reactions  given  below. 


8.3.4.3        Protected  Field 

The  field  is  protected  from  field  entry.  Violation  of  this  FEI  will  occur  if  an  attempt  is  made  to  change  the 
primary  or  secondary  attribute  of  any  array  element  of  this  field. 


8.3.4.4        Fill  Field 

All  array  elements  k=1  through  k=last  must  have  a  primary  attribute.  Violation  of  this  FEI  will  occur  if  any 
array  element  of  this  field  is  empty  when  one  of  the  reactions  FER01  (Transmit  updates)  or  FER02 
(Relinquish  WAVAR)  is  initiated.  See  also  the  specification  of  these  reactions  given  below. 


8.3.4.5        Echo  Received  Character 

Allowed  field  entry  characters  are  to  be  echoed  as  received.  This  FEI  is  provided  for  completeness  only, 
as  by  default  characters  will  be  echoed  as  received  unless  the  field  is  linked  to  either  the  Echo  Off  or  the 
Echo  Specified  Character  FEI.  This  FEI  can  never  be  violated. 


8.3.4.6         Echo  Off 

Received  field  entry  characters  should  not  be  echoed.  This  FEI  can  never  be  violated. 


8.3.4.7        Ignore  Case 

If  this  FEI  is  linked  to  a  field,  upper  and  lower  case  alphabetic  characters  should  be  considered  as  equivalent 
during  the  validation  of  field  input  against  all  other  FEIs  linked  to  the  same  field.  This  affects  the 
interpretation  of  the  Allowed  First  Characters,  Allowed  Characters,  Disallowed  Characters  and  Allowed  String 
Values  FEIs,  including  the  precedence  rules  between  the  first  three  of  these  FEIs.  This  FEI  can  never  be 
violated. 


8.3.4.8        Inhibit  Logical  Rendition  Attribute  Operation 

No  form  of  logical  attribute  operation,  with  the  exception  of  character  repertoire  switching  as  given  below, 
can  be  performed  on  the  field.  Character  repertoire  changes  are  permitted  if  also  permitted  by  Allowed  First 
Characters  or  Allowed  Characters,  see  below.  This  FEI  is  intended  to  be  used  when  the  rendition  secondary 
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attributes  are  to  be  l<ept  under  "application"  control.  See,  for  exannple,  Allowed  First  Characters  for  a  case 
of  reference  to  the  field  modal  values. 


8.3.5       DYNAMIC  Field  Entry  Instruction  Definitions  -  parametric 


8.3.5.1  Selectable  field 

The  field  is  selectable,  i.e.,  field  entry  is  not  permitted  but  information  is  conveyed  by  the  selection  of  one 
such  field  from  a  number  of  alternatives. 

The  manner  in  which  the  field  that  is  the  current  candidate  for  selection  is  displayed  on  the  real  device  is 
determined  by  the  optional  "visit"  parameter  of  this  FEI.  This  parameter  specifies  the  secondary  attributes 
to  be  used  for  showing  or  highlighting  this  candidate  to  the  user.  If  it  is  omitted,  an  implementation- 
dependent  default  is  used. 

The  manner  in  which  the  field  that  is  actually  selected  is  displayed  on  the  real  device  is  determined  by  the 
optional  "select"  parameter  of  this  FEI.  This  parameter  specifies  the  secondary  attributes  to  be  used  for 
showing  or  highlighting  the  selected  field  to  the  user.  If  it  is  omitted,  an  implementation-dependent  default 
is  used. 

t 

I  The  mechanisms  for  moving  among  candidates  and  for  actually  selecting  the  current  candidate  are 
1  implementation  defined.  Typically,  a  selectable  field  will  be  considered  as  a  candidate  for  selection  when 
I  the  cursor  is  placed  on  a  character  within  the  selectable  field.  Actual  selection  generates  the  Field  Selected 
FEE.  A  selected  field  is  indicated  in  a  delivered  update  by  an  addressing  operation  setting  k=1  and  f  and 
z  to  indicate  the  selected  field.  These  values  will  be  reported  to  the  host  in  the  CCO  if  WAVAR  is 
j  relinquished  in  reaction  to  this  FEE.  Violation  of  this  FEI  will  occur  if  an  attempt  is  made  to  change  the 
I     primary  or  secondary  attribute  of  any  array  element  of  this  field. 

8.3.5.2  Echo  Specified  Character 

I     Specifies  the  character  which  is  to  be  echoed  to  the  user  in  response  to  each  allowed  character  entered 
into  the  field.  The  secondary  attributes  of  the  echoed  character  may  be  specified.  Any  secondary  attribute 
j     that  is  not  given  an  explicit  value  in  the  FEI  takes  a  default  value  in  accordance  with  Definitive  Note  4.  This 
I    FEI  can  never  be  violated. 

1 

8.3.5.3  Minimum  Entry 

^  All  array  elements  k=  1  through  k= Minimum  Entry  must  have  a  primary  attribute.  If  Minimum  Entry  exceeds 
J  field  size,  then  all  positions  in  the  field  must  be  filled.  Violation  of  this  FEI  will  occur  if  any  of  the  specified 
array  elements  are  empty  when  one  of  the  reactions  FER01  (Transmit  updates)  or  FER02  (Relinquish 
WAVAR)  is  initiated.  See  also  the  specification  of  these  reactions  given  below.  When  a  field  is  associated 
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with  both  the  Optional  Field  FEI  and  a  Minimum  Entry  FEI,  the  field  is  optional  but  if  entry  is  elected,  the 
number  of  characters  specified  by  the  Minimum  Entry  FEI  must  then  be  entered. 


Specifies  a  set  of  allowed  characters  for  the  first  character  position  of  the  field.  Either  primary  attributes 
alone  or  both  primary  and  secondary  attributes  may  be  checl<ed;  see  Definitive  Note  3. 


Specifies  a  set  of  allowed  characters  for  all  character  positions  within  the  field.  Either  primary  attributes 
alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note  3.  If  Allowed  First 
Characters  and  Allowed  Characters  are  both  specified  for  a  particular  field,  then  the  set  of  Allowed  First 
Characters  applies  to  the  first  character  position  of  the  field  and  the  set  of  Allowed  Characters  applies  to 
the  second  through  last  character  positions  of  the  field. 


8.3.5.6        Disallowed  Characters 

Specifies  a  set  of  disallowed  characters  for  all  character  positions  within  a  field.  Either  primary  attributes 
alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note  3.  If  Allowed  First 
Characters  and  Disallowed  Characters  are  both  specified  for  a  particular  field,  then  the  set  of  Allowed  First 
Characters  applies  to  the  first  character  position  of  the  field  and  the  set  of  Disallowed  Characters  applies 
to  the  second  through  last  character  positions  of  the  field.  When  a  field  is  associated  with  Allowed 
Characters  FEI(s)  and  Disallowed  Characters  FEI(s)  that  have  characters  in  common,  the  common 
characters  are  considered  as  disallowed. 


8.3.5.7        Entry  Invoke  Character 

Specifies  the  attributes  to  be  used  for  showing  or  highlighting  to  the  user  where  the  next  character  entry  is 
to  be  made.  Both  primary  and  secondary  attributes,  or  secondary  attributes  alone,  may  be  specified  to 
over-ride  the  corresponding  values  present  in  the  array  element  concerned.  Any  secondary  attribute  that 
is  not  given  an  explicit  value  in  the  FEI  takes  a  default  value  in  accordance  with  Definitive  Note  4.  Fields 
that  are  not  linked  to  an  Entry  Invoke  Character  FEI,  utilize  a  device  dependent  entry  invoke  character 
which  may  or  may  not  be  represented  in  the  character  repertoire  negotiated  for  the  device.  This  FEI  can 
never  be  violated. 


8.3.5.8        Waiting  Time 

Specifies  the  number  of  seconds  to  wait  for  field  entry  to  complete  after  the  cursor  has  been  positioned 
within  the  field.  Fields  that  are  not  associated  with  a  Waiting  Time  FEI  are  not  subject  to  the  "Field  Waiting 


8.3.5,4 


Allowed  First  Characters 


8.3.5.5 


Allowed  Characters 
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Time  Expired"  Field  Entry  Event.  Note  tliat  an  overall  waiting  time  for  an  entire  form  may  be  set  by  use  of 
the  Vaiting-time"  control  object  defined  in  Definitive  Note  1.  This  FEI  can  never  be  violated. 


8.3.5.9        Allowed  String  Values 

Specifies  a  list  of  strings  which  identify  valid  field  values.  The  strings  are  specified  as  either  a  discrete 
OCTET  STRING  or  a  range  of  OCTET  STRING,  or  combination  of  both. 

Ranges  are  specified  using  a  lower  "value"  OCTET  STRING  and  a  higher  "value"  OCTET  STRING.  The 
"value"  of  an  OCTET  STRING  is  the  integer  value  derived  from  the  collating  sequence  corresponding  to  the 
repertoire  explicitly  or  implicitly  specified  for  the  OCTET  STRING.  For  example,  the  ISO  646  string  'AB'  has 
the  integer  value  4142(16)  and  the  string  'ABC  has  the  value  414243(16). 

When  strings  of  unequal  length  are  compared,  the  smaller  string  is  filled  on  the  right  with  enough  spaces 
to  make  the  strings  of  equal  length.  The  comparison  of  ISO  646  strings  'AB'  and  'ABC  would  be 
accomplished  by  first  converting  the  string  'AB'  to  'AB'  thus  creating  the  value  414220(16)  to  be  compared 
against  the  value  414243(16).  The  value  of  the  space  character  is  derived  from  the  collating  sequence 
corresponding  to  the  repertoire  identified  in  the  field  modal  attributes.  If  this  repertoire  does  not  contain  a 
space,  then  the  value  20(16)  is  used. 

Either  primary  attributes  alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note 
3.  A  single  set  of  secondary  attribute  values  may  be  specified  for  each  individual  OCTET  STRING  or  range 
of  OCTET  STRINGS. 


8.3.5.10       Allowed  Mumeric  Values 

Specifies  a  list  of  numeric  strings  which  identify  valid  field  values.  The  strings  are  specified  as  either  a 
discrete  OCTET  STRING  or  a  range  of  OCTET  STRING,  or  a  combination  of  both. 

'     Ranges  are  specified  using  a  lower  "value"  OCTET  STRING  and  a  higher  "value"  OCTET  STRING.  The 
"value"  of  an  OCTET  STRING  is  the  integer  value  derived  from  the  collating  sequence  corresponding  to  the 
!     repertoire  explicitly  or  implicitly  specified  for  the  OCTET  STRING.  For  example,  the  ISO  646  string  '12'  has 
■i     the  integer  value  3132(16)  and  the  string  '123'  has  the  integer  value  313233(16). 

f 

I  When  strings  of  unequal  length  are  compared,  the  smaller  string  is  filled  on  the  left  with  enough  zero 
I  characters  to  make  the  strings  of  equal  length.  The  comparison  of  ISO  646  strings  '12'  and  '123'  would  be 
accomplished  by  first  converting  the  string  '12'  to  '012'  thus  creating  the  value  303132(16)  to  be  compared 
against  the  value  313233(16).  The  value  of  the  zero  character  is  derived  from  the  collating  sequence 
corresponding  to  the  repertoire  identified  in  the  field  modal  attributes.  If  this  repertoire  does  not  contain  a 
zero,  then  the  value  30(16)  is  used. 


I 
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Either  primary  attributes  alone  or  botli  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note 
3.  A  single  set  of  secondary  attribute  values  may  be  specified  for  each  individual  OCTET  STRING  or  range 
of  OCTET  STRINGS. 


8.3.6       Mutually  Exclusive  FEIs 

Some  FEIs  specify  field  entry  validation  rules  that  are  in  conflict  with  the  rules  specified  by  other  FEis.  For 
example,  a  particular  field  cannot  be  both  "protected'  and  "mandatory."  Such  conflicting  FEIs  cannot  be 
associated  with  the  same  field.  Table  9  defines  the  sets  of  conflicting  FEIs. 
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Table  9  -  Sets  of  conflicting  FEIs 


FEI 

Conflicting  FEIs 

Optional  Field 

Mandatory  Field,  Selectable  Field,  Protected  Field 

Mandatorv  Field 

Ootional  Field     Seler't'able  Field     Pro1"er'i"ed  Field 

Selectable  Field 

AX  1  ©xcAT^t  "Rnl"  r V  Tnvolcp'  r^ha r act*  p r  and  Wa  1 1*  i  nn  T i  mp 

Protected  Field 

All 

Fill  Field 

Selectable  Field,  Protected  Field,  Allowed  String 
Values,  Allowed  Numeric  Values 

Echo  Received 
Character 

Selectable  Field,  Protected  Field,  Echo  Off,  Echo 
Specified  Character 

Echo  Off 

Selectable  Field,  Protected  Field,  Echo  Received 
Character,  Echo  Specified  Character 

Ignore  Case 

Selectable  Field,  Protected  Field 

Inhibit  Logical 
Rendition 

Attribute  Operation 

Selectable  Field,  Protected  Field 

Echo  Specified 
Pharaot'er 

Selectable  Field,  Protected  Field,  Echo  Off,  Echo 
Received  Character 

MiniTniim  Entrv 

Selectable  Field,  Protected  Field 

Allowed  First 
Characters 

Selectable  Field,  Protected  Field,  Allowed  String 
Values,  Allowed  Numeric  Values 

Allowed  Characters 

Selectable  Field,  Protected  Field,  Allowed  String 
Values,  Allowed  Numeric  Values 

Disallowed  Characters 

Selectable  Field,  Protected  Field,  Allowed  String 
Values,  Allowed  Numeric  Values 

Entry  Invoke  Character 

Protected  Field 

Waiting  Time 

Protected  Field 

Allowed  String  Values 

Selectable  Field,  Protected  Field,  Fill  Field, 
Allowed  First  Characters,  Allowed  Characters, 
Disallowed  Characters,  Allowed  Numeric  Values 

Allowed  Numeric  Values 

Selectable  Field,  Protected  Field,  Fill  Field, 
Allowed  First  Characters,  Allowed  Characters, 
Disallowed  Characters,  Allowed  String  Values 
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8.3.7       FEICO  Update  Syntax 

In  the  following  syntax,  ASN.1  Value  Assignments  have  been  used  to  attach  value  references  to  values  of 
type  NULL  This  enables  the  values  to  be  referenced  by  these  names  alone,  without  the  need  to  follow  the 
identifier  explicitly  with  the  value  NULL 


FEI  DEFINITIONS  ::=  BEGIN 


FEI  ::=  CHOICE  { 

feiO 

[0] 

IMPLICIT  NULL, 

feil 

[1] 

IMPLICIT  NULL, 

fei2 

[2] 

IMPLICIT  NULL, 

feiS 

[3] 

IMPLICIT  NULL, 

fel4 

[4] 

IMPLICIT  NULL, 

feiS 

[5] 

IMPLICIT  NULL, 

feia 

[6] 

IMPLICIT  NULL, 

fei7 

[7] 

[8] 

IMPLICIT  NULL, 

selectableFleld 

IMPLICIT  SEQUENCE  { 

visit     [0]  IMPLICIT  SecAttributes  OPTIONAL, 
select  [1]  IMPLICIT  SecAttributes  OPTIONAL  }, 

IMPLICIT  Character, 
IMPLICIT  INTEGER, 
IMPLICIT  CharacterValues, 
IMPLICIT  CharacterValues, 
IMPLICIT  CharacterValues, 
CHOICE  { 

}, 

IMPLICIT  INTEGER, 
IMPLICIT  CharacterValues, 
IMPLICIT  CharacterValues  } 

::=  feiO  NULL 
::=  fei1  NULL 
::=  fei2  NULL 
::=  feiS  NULL 
::=  fei4  NULL 
::=  feiS  NULL 
::=  fei6  NULL 
::=  fei7  NULL 


echoSpecifiedCharacter  [9] 
minimumEntries  [10] 
allowedFlrstCharacters  [11] 
allowedCharacters  [12] 
disallowedCharacters  [13] 
entrylnvokeCharacter  [14] 
[0]  IMPLICIT  Character, 
[1]  IMPLICIT  SecAttributes 


waitingTinne 

[15] 

allowedStringValues 

[16] 

allowedNumericValues 

[17] 

optionalField 

FEI 

mandatory  Field 

FEI 

protected  Field 

FEI 

fillField 

FEI 

echoReceivedChar 

FEI 

echoOff 

FEI 

ignoreCase 

FEI 

InhibitLogRendAttOp 

FEI 

Character  ::=  SEQUENCE  { 

prinnaryValue  [0]      IMPLICIT  PriValue, 
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attributes       [1]      IMPLICIT  SecAttributes  OPTIONAL } 
--  When  used  as  one  element  of  a  comparison,  secondary 
--  attributes  are  to  be  compared  only  if  the  attributes 
--  element  is  present. 

CharacterValues  ::=  SEQUENCE  OF  SEQUENCE  { 

lowValue  [0]      IMPLICIT  Character, 

highValue  [1]      IMPLICIT  PriValue  OPTIONAL } 

-  The  default  for  highValue  is  the  associated 

--  lowValue.  Octet  values  specified  for  highValue 

"  are  constrained  by  the  repertoire  corresponding 

--  to  the  lowValue  value.  The  relationship 

--  [lowValue  <  =  highValue]  must  be  true. 

PriValue  ::=  OCTET  STRING 

--  The  octet  string  comprising  a  value  of  the  PriValue 
--  type  is  constrained  to  the  encoding  of  a  sequence 
--  of  characters  from  the  repertoires  negotiated  for 
--  the  associated  Display  Object.  When  used  in  the 
--  ASN.1  module  FEI,  the  octet  string  is  restricted  to 
--  the  encoding  of  a  single  character  except  for  its 
--  use  in  allowedStringValues  and  allowedNumeric- 
--  Values. 

SecAttributes  ::=  SEQUENCE  { 


repertoire 

[0] 

IMPLICIT  INTEGER  OPTIONAL, 

foregroundColour 

[1] 

IMPLICIT  INTEGER  OPTIONAL, 

backgroundColour 

[2] 

IMPLICIT  INTEGER  OPTIONAL, 

emphasis 

[31 

IMPLICIT  PrintableString  OPTIONAL, 

font 

[4] 

IMPLICIT  INTEGER  OPTIONAL  } 

END  *(FEI  DEFINITIONS)* 

8.3.8       FEICO  "mandatory-feico "  Initial  Content 

For  each  FEIRxx,  xx  identifies  the  integer  value  to  be  used  as  "feirList  recordlndex"  in  FDCOUpdate 
operations.  FEICOUpdate  operations  must  use  an  "index"  greater  than  127.  Note  that  the  character 
oriented  FEIRs  for  the  initial  FEICO  utilize  the  default  secondary  attributes,  and  that  the  Selectable  Field  FEI 
uses  implementation-dependent  defaults  for  the  'visit'  and  'select'  secondary  attributes.  The  FEIR  contents 
are  specified  in  terms  of  ASN.1  Value  Notation  appropriate  to  the  FEICO  Update  Syntax  specified  above. 
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Table  10  -  FEICO  "mandatory-feico"  Initial  Content 


FEIR 

Value 

FEIROO 

—  not  used  — 

FEIROl 

optionalField 

FEIR02 

mandatoryField 

FEIR03 

selectableField  {  } 

FEIR04 

protectedField 

FEIR05 

f illField 

FEIR06 

echoReceivedCharacter 

FEIR07 

echoOf f 

FEIR08 

ignoreCase 

1  Iin  LDLX,  IjOgKenun  L  uup 

FEIRIO 

allowedCharacters  {{  lowValue  {MI'H}, 
ni gn value     da  n  j  j  —  a^s^  . . .  f  £>  — 

FEIRll 

allowedCharacters  { {  lowValue  { • 61 ' h} , 
nignvaiue     /a  n  j  j  — —  a^ . . . /Z  ■ — 

VV TOT  0 

all  r\TAi^f^r*Vk  aT-ai^-t-^-re     (  f    1  r\w\7^  lii^  /^•^n'wl 

ax xoweu^nar ac ters   \.  \,  xowvaxue   \.   ju  nj  / 
highValue  '39'U  )}  —  0,1,..., 9  -- 

FEIR13 

disallowedCharacters  {{  lowValue  {'41'H}, 
highValue  'SA'H  )}  —  A,B,...,Z  — 

FEIR14 

disallowedCharacters  {{  lowValue  {'61'H}, 
highValue  'TA'H  }}  —  a,b,...,z  — 

FEIR15 

disallowedCharacters  {{  lowValue  {'30'H}, 
highValue  '39'H  }}  —  0,1,..., 9  — 

FEIR16-FEIR127 

—  These  values  are  reserved  — 

8.3.9       Field  Entry  Event  Definitions 

The  Field  Entry  Events  for  the  mandatory  FEPCO  are  defined  in  the  following  subclauses.  A  parameter  of 
type  "Range"  is  a  sequence  of  integer  pairs,  each  witfi  an  optional  bitmask.  Each  pair  gives  the  end  points 
of  an  interval  of  integer  values.  An  integer  value  lies  within  the  range  specified  if,  after  applying  the  bitmask 
(if  given)  to  its  binary  form,  it  lies  in  any  of  these  intervals.  The  end  points  of  an  interval  are  included  in  the 
values  of  that  interval. 

It  is  permissible  for  the  ranges  specified  by  the  FEEs  referenced  in  the  entry  control  FEPR-list  of  a  field  to 
overlap.  When  an  event  occurs  which  is  referenced  in  this  way  by  more  than  one  FEPR  linked  to  the  current 
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field,  the  FEPR  invoked  is  the  first  FEPR  In  the  FEPR-list  which  both  references  the  event  and  for  which  the 
Field  Entry  Conditions  are  satisfied. 


8.3.9.1  FEEOO 

Not  used. 


8.3.9.2        FEE01  Logical  Keystroke  event  (Range) 

This  event  takes  a  range  of  integers  as  a  parameter,  and  occurs  when  a  Logical  Keystroke  occurs  within 
the  specified  range.  The  Logical  Keystroke  is  either  initiated  by  the  Logical  Keystroke  FER  or  by  the  human 
user,  see  Definitive  Note  8. 


8.3.9.3        FEE02  Field  entry  complete 

This  event  is  generated  by  entry  of  a  character  into  the  last  position  in  a  field.  It  need  not  imply  that  all 
character  positions  in  the  field  have  been  entered,  since  these  positions  are  not  necessarily  written 
sequentially.  Local  cursor  movements,  for  example,  may  be  used  during  local  editing  to  move  the  current 
entry  position  around  the  screen. 


8.3.9.4        FEE03  Field  selected 

This  event  is  generated  by  the  selection  of  a  field  that  is  linked  to  the  Selectable  Field  FEI.  The  means  by 
which  the  current  candidate  for  selection  is  actually  selected  is  implementation  dependent. 


8.3.9.5        FEE04  Field  Waiting  Time  expired 

The  field  waiting  time  specified  by  the  Waiting  Time  FEI  linked  to  the  current  field  has  been  exceeded. 
Fields  not  linked  to  such  an  FEI  are  not  subject  to  this  event. 


8.3.9.6        FEE05  Field  Entry  Instruction  violation 

Some  of  the  defined  FEIs  imply  Field  Entry  Validation  by  the  terminal  VT-user.  Fields  linked  to  such  FEIs 
are  candidates  for  erroneous  field  entry.  This  event  is  generated  when  such  a  violation  occurs,  thus 
enabling  linkage  to  Field  Entry  Reactions  that  may  signal  a  visual  or  audible  indication  of  such  a  violation, 
or  alternatively  may  terminate  local  entry  and  relinquish  WAVAR.  A  Violation  FEC  is  available  to  allow 
different  reactions  according  to  which  FEIR  is  violated.  When  the  reaction  is  to  relinquish  WAVAR,  the  Entry- 
control  index  and  FEPR  index  elements  of  the  Context  Control  Object  will  inform  the  host  which  FEPR 
caused  the  return.  If  this  FEPR  has  made  use  of  the  Violation  FEC,  this  FEC  will  identify  to  the  host  that  the 
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violated  FEIR  was  one  of  those  in  the  list  that  forms  the  paranrieter  value  for  the  FEC.  Unique  identification 
of  the  FEIR  is  obtained  if  this  list  contains  only  one  FEIR.  The  host  can  then  take  whatever  action  is 
appropriate  to  the  FEIR  or  FEIRs  so  identified. 


8.3.10      Field  Entry  Condition  Definitions 

The  elementary  Field  Entry  Conditions  for  the  mandatory  FEPCO  are  defined  below.  Composite  conditions 
can  be  built  by  use  of  the  specified  parameters,  and  an  individual  FEPR  can  include  multiple  conditions  in 
accordance  with  20.3.5.2  of  ISO  9040. 

A  parameter  of  type  Action  is  specified  either  as  an  explicit  integer  value  or  as  the  current  keystroke,  see 
Definitive  Note  8.  Such  a  parameter  evaluates  to  an  integer  of  the  type  STCO.Key  defined  in  clause  7.3.7. 
That  clause  also  defines  names  of  logical  keystrokes  associated  with  these  integers.  The  local  actions 
associated  with  such  values  are  defined  in  Definitive  Note  9. 

8.3.10.1  FECOO 
Not  used. 

8.3.10.2  FEC01  No  previous  field 

The  current  field  has  no  currently  defined  previous  field,  in  the  sense  of  20.3.3.4  of  ISO  9040. 

8.3.10.3  FEC02  No  next  field 

The  current  field  has  no  currently  defined  next  field,  in  the  sense  of  20.3.3.4  of  ISO  9040. 

8.3.1 0.4  FEC03  Start  of  field 

The  current  location  for  the  next  character  entry  is  at  the  first  location  in  the  current  field. 

8.3.10.5  FEC04  End  of  field 

The  current  location  for  the  next  character  entry  is  at  the  last  location  in  the  current  field. 
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8.3.1 0.6       FEC05  At  tab  stop 

The  current  location  for  the  next  character  entry  is  at  a  tabulation  stop  defined  by  the  optional  Horizontal 
Tabulation  CO  {ewos-vt-co-misc-ht}  registered  with  the  EWOS  Registration  Authority.  If  this  CO  is  not 
present  in  the  VTE,  this  condition  is  deemed  to  be  always  satisfied. 


8.3.10.7       FEC06  At  characters  (Set  of  character  values) 

The  current  location  for  the  next  character  entry  is  at  an  array  element  whose  current  value  is  one  of  the 
specified  characters.  The  set  of  characters  is  specified  arKl  interpreted  in  accordance  with  Definitive  Note 
3. 


8.3.10.8       FEC07  Exits  field  (Action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  current  field 


8.3.10.9       FEC08  Exits  forward  path  (Action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  forward  navigation  path  starting  at  the  current  field. 


8.3.10.10      FEC09  Exits  backward  path  (Action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  backward  navigation  path  starting  at  the  current  field. 


8.3.10.11      FEC10  Exits  x-array  (Action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  current  x-array. 


8.3.1 0.1 2      FEC1 1  Exits  y-array  (Action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  current  y-array. 
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8.3.10.13 


FECI  2  Not  FEC  (FEC) 


This  condition 


is  satisfied  precisely  when  the  FEC  given  as  its  parameter  is  not  satisfied. 


8.3.10.14 


FECI  3  And  FECs  (Set  of  FEC) 


This  condition  is  satisfied  when  each  of  the  conditions  in  the  set  comprising  its  parameter  is  satisfied. 


8.3.1 0.1 5      FECI  4  Or  FECs  (Set  of  FEC) 

This  condition  is  satisfied  when  at  least  one  of  the  conditions  in  the  set  comprising  its  parameter  is  satisfied. 


8.3.10.16      FECI  5  Violation  (Set  of  FEIR  Identifiers) 

This  condition  is  provided  for  use  in  conjunction  with  the  Field  Entry  Instruction  Violation  FEE.  Its  parameter 
is  an  FEIR-list  specified  as  a  set  of  FEIR  identifiers.  Each  identifier  is  a  pair  <FEICO-name,  index>  where 
index  is  an  integer  addressing  a  record  in  the  FEICO  whose  name  is  specified.  This  FEC  is  satisfied  if  the 
FEIR  whose  violation  generated  this  event  is  one  of  the  FEIRs  in  this  FEIR-list.  If  it  is  used  in  conjunction 
with  any  other  FEE  then  this  condition  is  true. 


8.3.10.17      FECI  6  Unconditional 

This  condition  is  always  true.  It  is  given  for  completeness  only,  and  has  the  same  effect  as  an  empty  set 
of  conditions  in  an  FEPR. 


8.3.11      Field  Entry  Reaction  Definitions 

The  Field  Entry  Reactions  for  the  mandatory  FEPCO  are  defined  below.  The  significance  of  a  parameter 
of  type  "Action"  is  as  described  for  Field  Entry  Conditions.  A  parameter  of  type  "ResetAttribute"  may  take 
either  of  the  two  values  "reset"  and  "noReset."  Such  a  parameter  controls  the  effect  of  an  erase  operation 
on  the  secondary  attributes  of  the  erased  elements,  corresponding  to  the  values  "yes"  and  "no"  for  the  reset- 
attribute  parameter  of  a  LOGICAL-ERASE  operation  as  defined  in  19.2.3.5  of  ISO  9040. 


8.3.11.1 


FEROO 


Not  used. 
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8.3.11.2       FER01  Transmit  updates 

The  host  copy  of  the  CCA  is  updated  to  correspond  to  the  terminal  copy  by  the  transmission  of  all 
undelivered  update  operations.  The  operations  required  to  update  field  contents  are  controlled  by  the  T- 
policy  component  of  the  Field  Definition  Record  for  the  fields  concerned.  However,  if  this  FER  generates 
an  FEI  violation  in  accordance  with  the  specifications  of  the  FEICO(s)  present  in  the  VTE.  and  if  the  current 
field  is  also  linked  to  an  FEPR  with  event  FEE05  (FEI  violation)  and  satisfied  conditions,  then  this  FER  is  not 
performed  and  that  FEPR  is  activated;  the  original  FEPR  is  abandoned. 


8.3.1 1 .3       FER02  Relinquish  WAVAR 

The  action  described  under  Transmit  Updates  is  performed,  followed  by  return  of  the  WAVAR  access  right 
to  the  host.  However,  if  this  FER  generates  an  FEI  violation  in  accordance  with  the  specifications  of  the 
FEICO(s)  present  in  the  VTE,  and  if  the  current  field  is  also  linked  to  an  FEPR  with  event  FEE05  (FEI 
violation)  and  satisfied  conditions,  then  this  FER  is  not  performed  and  that  FEPR  is  activated;  the  original 
FEPR  is  abandoned. 


8.3.11.4       FER03  Erase  field  right  (Reset  attribute) 

The  primary  attribute  value  is  cancelled  for  all  elements  of  the  current  field  from  the  current  character  entry 
location  to  the  end  of  the  field.  The  effect  on  the  secondary  attribute  values  is  determined  by  the  reset- 
attribute  parameter  as  described  above. 


8.3.11.5       FER04  Erase  path  right  (Reset  attribute) 

The  primary  attribute  value  is  cancelled  for  all  elements  of  all  unprotected  fields  in  the  fonA/ard  navigation 
path  containing  the  current  field,  from  the  current  character  entry  location  onwards.  Note  that  the  forward 
navigation  path  may  not  terminate,  as  its  definition  in  20.3.3.4  of  ISO  9040  does  not  prohibit  looping.  When 
a  loop  is  entered  during  this  operation,  the  operation  terminates  when  all  elements  of  the  entered  loop  have 
been  erased.  The  effect  of  this  operation  on  the  secondary  attribute  values  is  determined  by  the  reset- 
attribute  parameter  as  described  above. 

i     8.3.11.6       FER05  Local  action  (Action) 

That  local  action  is  performed  which  is  designated  by  the  given  parameter  value.  The  specification  of  these 
local  actions  is  given  in  Definitive  Note  9. 


43 


PART  14  -  VIRTUAL  TERMINAL 


December  1990  (Stable) 


8.3.1 1 .7       FER06  Logical  Keystroke  (Action) 

Initiate  tlie  FEPR  processing  wtiich  would  occur  if  the  given  keystroke  had  occurred.  This  may  itself  cause 
the  Logical  Keystroke  FER  and  hence  recursive  processings  of  FERs.  Processing  of  current  FERs  is 
suspended  until  this  recursive  processing  is  complete.  During  recursive  processing,  the  current  keystroke 
is  taken  as  the  argument  to  this  FER.  When  the  recursive  processing  is  complete,  the  previous  keystroke 
is  restored  and  processing  of  current  FERs  is  resumed. 


8.3.1 1 .8       FER07  Update  ST  CO  (Action) 

The  integer  value  corresponding  to  the  given  parameter  is  written  to  the  Sequenced  Terminal  CO.  This  FER 
will  usually  be  followed  by  a  Transmit  Updates  or  Relinquish  WAVAR  FER  to  communicate  the  update  to  the 
application. 


8.3.1 1 .9       FER08  Update  UT  CO  (Action) 

The  integer  value  corresponding  to  the  given  parameter  is  written  to  the  Unsequenced  Terminal  CO.  This 
update  will  be  communicated  to  the  application  immediately. 


8.3.11.10      FER09  Execute  RIO  record  (RIO  record  Id) 

An  EXECUTE-RECORD  operation  is  performed  on  the  RIO  record  specified  in  the  parameter,  in  accordance 
with  22.4.1  of  ISO  9040. 


8.3.1 1 .1 1      FER01 0  Call  RIO  record  (RIO  record  id) 

A  CALL-RECORD  operation  is  performed  on  the  RIO  record  specified  in  the  parameter,  in  accordance  with 
22.4.2  of  ISO  9040. 


8.3.11.12      FER11  Visual  indication 

Present  a  visual  indication  in  response  to  Field  Entry  Instruction  violations. 


8.3.1 1.13      FER1 2  Audible  indication 

Present  an  audible  indication  in  response  to  Field  Entry  Instruction  violations. 
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(if:  FEC,  then:  Optional  sequence  of  PER,  else  :  Optional  sequence  of  FER) 

If  the  condition  given  by  the  "If'  parameter  is  satisfied  then  perform  the  sequence  of  reactions  given  by  the 
'then"  parameter,  else  perform  the  sequence  of  reactions  given  by  the  "else"  parameter. 


8.3.1 1.15      FER1 4  Prevent  further  entry 

It  is  recommended  that  If  a  type-ahead  buffer  is  in  use  by  the  local  user  interface,  this  reaction  should 
prevent  further  entry  into  the  buffer.  Attempted  entry  may  then  sound  an  alarm  or  be  signalled  by  some 
other  local  means,  but  is  not  an  FEI  violation.  If  the  WAVAR  access  right  is  relinquished  without  this  reaction 
being  invoked,  the  buffer  may  continue  to  accept  entries.  Entry  Into  the  buffer  is  resumed  when  WAVAR 
is  next  returned  to  the  terminal.  It  is  not  a  violation  of  this  profile  specification  if  the  terminal  VT-user  does 
not  behave  in  the  intended  manner. 


8.3.1 1.16      FER1 5  Write  disallowed  character 

The  most  recent  disallowed  character  is  written  as  if  it  were  not  disallowed.  If  there  has  been  no  disallowed 
character,  the  effect  is  null.  This  FER  is  used  when  it  is  desired  to  trap  the  entry  of  a  particular  character, 
not  to  forbid  it  but  instead  to  generate  some  other  reactions  in  addition  to  the  character  entry. 


8.3.1 1.17      FER1 6  Write  string  (Character  string) 

The  character  string  given  as  a  parameter  is  written  as  LOGICAL  TEXT  to  the  current  entry  location  without 
regard  to  FEICO  control.  If  the  end  of  the  field  is  reached  before  the  string  has  been  written  in  its  entirety, 
the  reaction  is  terminated  prematurely. 


8.3.12      Field  Entry  Pilot  Update  Syntax 

In  the  following  syntax,  ASN.1  Value  Assignments  have  been  used  to  attach  value  references  to  values  of 
type  NULL.  This  enables  the  values  to  be  referenced  by  these  names  alone,  without  the  need  to  follow  the 
identifier  explicitly  with  the  value  NULL 
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FEPR  DEFINITIONS  ::=  BEGIN 


FEE  ::=  CHOICE  { 

logicalKeystroke 

fee02 

fee03 

fee04 

fee05 


[1]  IMPLICIT  Range, 
[2]  IMPLICIT  NULL, 
[3]  IMPLICIT  NULL, 
[4]  IMPLICIT  NULL, 
[5]  IMPLICIT  NULL  } 


fieldEntryComplete  FEE 

fieldSelected  FEE 

fieldWaitTimeExpired  FEE 

feiViolation  FEE 


=  fee02  NULL 
=  feeOS  NULL 
=  fee04  NULL 
=  fee05  NULL 


FEC  ::=  CHOICE  { 

fec01 

[1]  IMPLICIT  NULL, 

fec02 

[2]  IMPLICIT  NULL, 

fecOS 

[3]  IMPLICIT  NULL, 

fec04 

[4]  IMPLICIT  NULL, 

fec05 

[5]  IMPLICIT  NULL, 

atChar 

[6]  IMPLICIT  FEI.CharacterValues, 

exitsFleld 

[7]  Action, 

exitsForwardPath 

[8]  Action, 

exitsBackward  Path 

[9]  Action, 

exitsXarray 

[10]  Action, 

exits Yarray  ' 

[11]  Action, 

not 

[12]  FEC, 

and 

[13]  IMPLICIT  SET  OF  FEC, 

or 

[14]  IMPLICIT  SET  OF  FEC, 

violation 

[15]  IMPLICIT  SET  OF  SEQUENCE 

{  feicoName  PrintableStrinc 

recordlndex    INTEGER  }, 

fec16 

[16]  IMPLICIT  NULL  } 

noPreviousFleid 

FEC  ::=  fecOl  NULL 

noNextField 

FEC  ::=  fec02  NULL 

startField 

FEC  ::=  fec03  NULL 

endFleld 

FEC  ::=  fec04  NULL 

atTab 

FEC  ::=  fec05  NULL 

unconditional 

FEC  ::=  fec16  NULL 
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FER  ::=  CHOICE  { 


fer01 

[1] 

fer02 

[2] 

eraseFieldRight 

[3] 

erasePath  Right 

[4] 

local 

[5] 

logicalKeystroke 

[6] 

updateSTCO 

[7] 

updateUTCO 

[8] 

executeRIO 

[9] 

callRIO 

[10] 

fer11 

[11] 

fan  2 

[12] 

branch 

[13] 

IMPLICIT  NULL, 

IMPLICIT  NULL, 

IMPLICIT  ResetAttribute, 

IMPLICIT  ResetAttribute, 

Action, 

Action, 

Action, 

Action, 

IMPLICIT  RIORecordID, 


if        [1]  FEC, 

then     [2]  IMPLICIT  SEQUENCE  OF  FER  OPTIONAL, 
else     [3]  IMPLICIT  SEQUENCE  OF  FER  OPTIONAL  }, 

fer14  [14]  IMPLICIT  NULL, 

fer15  [15]  IMPLICIT  NULL, 

writeString  [16]  IMPLICIT  SEQUENCE  OF 

FEI. Character 

--  The  string  written  by  this  FER  is  the 

-  concatenation  of  the  strings  specified  by 

--  the  individual  FEI.Character  values.  -■  } 


transmitUpdates 

FER  : 

:  =  ferOI 

NULL 

relinquishWAVAR 

FER  : 

:  =  fer02 

NULL 

visuallndication 

FER  : 

:  =  ferl  1 

NULL 

audiblelndication 

FER  : 

:=  ferl  2 

NULL 

preventFurtherEntry 

FER  : 

:=  ferl  4 

NULL 

writeDisallowedChar 

FER  : 

:=  ferl  5 

NULL 

RIORecordID  ::=  SEQUENCE  { 

rioName  [1]  IMPLICIT  PrintableString  OPTIONAL, 

--  optional  if  there  is  only  1  RIO  in  the  VTE 
recordID  [2]  IMPLICIT  PrintableString  } 


Range  ::=  SEQUENCE  OF  SEQUENCE  { 

[1]  IMPLICIT  STCO.Key, 
[2]  IMPLICIT  STCO.Key  OPTIONAL, 
mask  [3]  IMPLICIT  BIT  STRING  OPTIONAL  } 
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--  The  first  two  values  of  each  trio  represent  an 
--  interval  of  logical  keystroke  values.  The  second 
--  value  in  each  pair  shall  not  be  smaller  than  the 

first  value.  If  the  second  value  is  omitted,  the 
--  interval  contains  only  the  specified  first  value. 
--  If  the  optional  mask  is  given,  then  the  value  being 
--  tested  is  bitwise  logically  ANDed  with  the  mask 
--  before  being  compared  with  the  end  points  of  the 
-  interval. 


ResetAttribute  ::=  BOOLEAN 

reset  ResetAttribute  ::=  TRUE 

noReset  ResetAttribute  ::=  FALSE 

Action  ::=  CHOICE  { 

[1]  IMPLICIT  STCO.Key, 
current  [2]  IMPLICIT  NULL  } 

currentKeystroke   Action  ::=  current  NULL 

-  The  ASN.1  module  STCO  is  defined  in  the  specification  of 
--  the  Sequenced  Terminal  CO  in  clause  7.3.  STCO.Key  is 
--  an  integer  type  with  a  named  number  list,  each  named 
--  number  representing  a  specific  logical  keystroke  as 
--  defined  for  that  CO. 


END  *(FEPR  DEFINITIONS)* 


FEPCO  "mandatory-fepco"  Initial  Content 

For  each  FEPRxx,  xx  Identifies  the  integer  value  to  be  used  as  "feprList  recordlndex"  in  FDCOUpdate 
operations.  FEPCOUpdate  operations  must  use  an  "Index"  greater  than  127.  The  FEPR  contents  are 
specified  in  ternns  of  ASN.1  Value  Notation  appropriate  to  the  FEPCO  Update  Syntax  specified  above.  Note 
that  "shiftTab"  is  a  named  integer  of  type  STCO.Key.  The  local  action  it  designates  is  defined  in  Definitive 
Note  9  to  be  movement  of  the  current  character  entry  position  to  the  first  location  of  the  next  field  in  the 
fonward  navigation  path. 
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Table  1 1  -  FEPCP  "mandatory-fepco"  Initial  Content 


FEPR  No 

Component 

ASN.l  Descrip'tion 

FEPROO 

— Not  used — 

FEPROl 

FEE 

loaicalKevstroke  f  f  0.  65535  )  } 

FEC 

uncond  i  t  i  onal 

FEROl 

updateSTCO  currentKeystroke 

FER02 

r e 1 i nqu i s h WAVAR 

FEPR02 

FEE 

f ieldEntryComplete 

FEC 

noNextField 

FER 

r e 1 i nqu i s hW AVAR 

FEPR03 

FEE 

f ieldEntryComplete 

FEC 

not  noNextField 

FER 

local  shiftTab 

FEPR04 

FEE 

f ieldSelected 

FEC 

uncond  i  t  i  ona 1 

FER 

r e 1 i nqu i s hWAVAR 

FEPR05 

FEE 

f ieldWaitTimeExpired 

FEC 

noNextField 

FER 

r  e 1 i  nqu  i  shWAVAR 

FEPR06 

FEE 

f  ieldWai  tTimeExpi  red 

FEC 

not  noNextField 

FER 

local  shiftTab 

FEPR07 

FEE 

feiViolation 

FEC 

uncond  i  t  i  onal 

FER 

visual Indication 

FEPR08 

FEE 

feiViolation 

FEC 

uncond  i  t  i  ona 1 

FER 

audiblelndication 

FEPR09- 

—  Reserved  — 

FEPR127 

8.3.13      Profile  Arguments 

r1  -    is  optional  and  provides  for  the  negotiation  of  a  value  for  tlie  VTE-parameter  x-bound. 
integer  value  greater  than  zero.  Default  Is  80. 

r2  -    is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  y-bound. 
Integer  value  greater  than  zero.  Default  Is  24. 

r3  -    is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  z-wlndow 
Integer  value  greater  than  zero.  Default  is  1 . 
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r4  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  repertoire-assignment.  The  value  for  the  VTE-parameter 
repertoire-capability  is  implied  by  the  number  of  occurrences  of  this  profile  argument.  Default  is  a 
single  occurrence  with  the  value  {value  iso2022  {'2842'H}}  of  ASN.1  type 
CDS.RepertoireAssignment  as  defined  in  ISO  9041,  designating  the  GL  set  ISO  2375  Reg.  No.  6 
(ASCII). 

r5  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
va!ue(s)  for  the  VTE-parameter  font-assignment.  The  font-assignment-type  component  of  a  font- 
assignment  value  is  an  ASN.1  OBJECT  IDENTIFIER  that  designates  a  registered  syntax  and 
semantics  for  the  font-assignment-value  component.  The  value  forthe  VTE-parameter  font-capability 
is  implied  by  the  number  of  occurrences  of  this  profile  argument.  If  there  are  no  explicit 
occurrences  of  this  profile  argument  then  the  font-capability  and  font-assignment  VTE-parameters 
take  the  default  values  specified  in  ISO  9040. 

r6  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  DO-emphasis.  The  syntax  and  semantics  for  this  VTE-parameter  are 
specified  in  Definitive  Note  6,  and  for  this  profile  argument  are  specified  in  B.17.4  of  ISO  9040.  The 
default  value  for  the  occurrence  corresponding  to  each  unspecified  subattribute  is  the  ASN.1 
PrintableString  of  length  1  specifying  the  explicit  modal  default  value  for  that  subattribute. 

r7  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameters 
foreground-colour-capability  and  background-colour-capability.  Default  is  8.  This  argument  is 
identified  by  the  identifier  for  the  VTE-parameter  foreground-colour-capability  for  display  object  A. 

r8  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  foreground-colour-assignment.  The  default  values  for  unspecified 
occurrences  of  this  profile  argument  are  the  corresponding  values  from  the  ordered  list  {"white," 
"black,"  "red,"  "cyan,"  "blue,"  "yellow,"  "green,"  "magenta"}.  There  are  no  default  values  if  the  value 
of  the  VTE-parameter  foreground-colour-capability  exceeds  8. 

r9  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  background-colour-assignment.  The  default  values  for  unspecified 
occurrences  of  this  profile  argument  are  the  corresponding  values  from  the  ordered  list  {"black," 
"white,"  "cyan,"  "red,"  "yellow,"  "blue,"  "magenta,"  "green"}.  There  are  no  default  values  if  the  value 
of  the  VTE-parameter  background-colour-capability  exceeds  8. 

r10  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  max-field-elements. 
Default  is  1 . 

r1 1  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  access-outside-fields. 
Default  is  "not  allowed." 

r12  -  is  mandatory  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  CO-access  for  the 
Field  Definition,  Field  Entry  Instruction,  Field  Entry  Pilot,  Transmission  Policy,  Sequenced 
Application,  Unsequenced  Application,  Sequenced  Terminal,  and  Unsequenced  Terminal  control 
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objects.  If  the  VT-association  initiator  is  tlie  terminal  VT-user.  it  takes  the  value  "WACA,"  otherwise 
it  takes  the  value  "WACI."  This  argument  is  identified  by  the  kJentifier  for  CO-access  for  control 
object  UA. 

r13  -  is  optional,  may  occur  a  number  of  times  and  provkJes  for  the  negotiation  of  a  value  for  the  VTE- 
parameter  CO-name  for  optional  registered  COs.  By  default  no  optional  COs  are  invoked. 

r14  -  is  optional,  may  occur  a  number  of  times  and  provWes  for  the  negotiation  of  a  value  for  the  VTE- 
parameter  CO-type-kJentlfier  for  optional  registered  COs.  The  particular  generic  type  concerned  is 
determined  from  the  CO-type-Wentifier  by  the  register  entry.  The  value  vt-b-sco-nullrio  selects  an 
empty  RIO.  An  occurrence  of  the  previous  argument  specifies  the  presence  of  an  optional  CO  in 
the  VTE-profile.  An  occurrence  of  this  argument  is  required  for  every  occurrence  of  the  previous 
argument.  By  default  no  optional  COs  are  Invoked. 

r15  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-repertoire-assignment  for  the  main  device.  Default  is  "null" 
for  each  unspecified  occurrence. 

r16  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-font-assignment  for  the  main  device.  Default  is  "null"  for  each 
unspecified  occurrence. 

r17  -  is  optional,  may  occur  a  number  of  times  In  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-emphasis  for  the  main  device.  The  syntax  and  semantics  for 
this  VTE-parameter  are  specified  in  Definitive  Note  6,  and  for  this  profile  argument  are  specified  in 
B.17.4  of  ISO  9040.  Default  is  "null"  for  each  unspecified  occurrence. 

r18  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-foreground-colour-assignment  for  the  main  device.  Default 
is  "null"  for  each  unspecified  occurrence. 

r19  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-background-colour-assignment  for  the  main  device.  Default 
is  "null"  for  each  unspecified  occurrence. 

r20  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
device-minimum-X-array-length  for  the  main  device.  It  takes  an  integer  value  greater  than  zero. 
Default  is  the  value  of  x-bound  for  the  display  object. 

r21  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
device-minimum-Y-array-length  for  the  main  device.  It  takes  an  integer  value  greater  than  zero. 
Default  is  the  value  of  y-bound  for  the  display  object. 

r22  -  is  optional,  may  occur  a  number  of  times  and  provides  for  the  negotiation  of  additional  values  for 
the  VTE-parameter  device-control-object  for  the  main  device.  By  default  there  are  no  additional 
values. 


51 


PART  14  -  VIRTUAL  TERMINAL 


December  1990  (Stable) 


r23  -  is  a  special  profile  argument  identified  by  the  special-profile-arg-ident  "Pp-1 ."  It  is  optional  and 
provides  for  the  negotiation  of  a  printer  device.  Default  is  "false." 

r24  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-repertoire-assignment  for  the  printer  device.  Default  is  "null" 
for  each  unspecified  occurrence.  j 

r25  -    is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a  | 
value(s)  for  the  VTE-parameter  device-font-assignment  for  the  printer  device.  Default  is  "null"  for  each  ' 
ii        unspecified  occurrence. 

r26  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-emphasis  for  the  printer  device.  The  syntax  and  semantics 
for  this  VTE-parameter  are  specified  in  Definitive  Note  6,  and  for  this  profile  argument  are  specified 
in  B.17.4  of  ISO  9040.  Default  is  "null"  for  each  unspecified  occurrence. 

r27  -    is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a  t 
value(s)  for  the  VTE-parameter  device-foreground-colour-assignment  for  the  printer  device.  Default 
is  "black"  for  each  unspecified  occurrence. 

r28  -    is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a  j, 
value(s)  for  the  VTE-parameter  device-background-colour-assignment  for  the  printer  device.  Default 
is  "white"  for  each  unspecified  occurrence. 

r29  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
device-minimum-X-array-length  for  the  printer  device.  It  takes  an  integer  value  greater  than  zero. 
Default  Is  the  value  of  x-bound  for  the  display  object. 

r30  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
device-minimum-Y-array-length  for  the  printer  device.  It  takes  an  integer  value  greater  than  zero. 
Default  is  the  value  of  y-bound  for  the  display  object.  i 

r31  -  is  optional,  may  occur  a  number  of  times  and  provides  for  the  negotiation  of  additional  values  for 
the  VTE-parameter  device-control-object  for  the  printer  device.  By  default  there  are  no  additional 
values. 


8.3.14      Profile  Dependent  Control  Objects 

This  profile  uses  the  OIW  registered  Control  Objects  SA,  UA,  ST  and  UT.  The  profile  defined  values  are 
specified  in  the  body  of  this  profile.  The  CO  specifications  require  the  usage  of  each  CO  to  be  specified 
in  the  profile.  This  is  as  follows. 
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8.3.14.1       Sequenced  Application  CO 

This  Control  Object  is  defined  in  7.1.  It  has  CO-category  "symbolic."  Update  of  this  CO  with  the  value 
"audible_alarm"  sounds  an  audible  alarm  in  the  terminal.  Update  with  the  value  'Visual  alarm"  generates  a 
visual  indication  of  a  signal  from  the  application.  All  other  values  have  no  effect. 


8.3.14.2       Unsequenced  Application  CO 

This  Control  Object  is  defined  in  7.2.  It  has  CO-category  "symbolic."  Update  of  this  CO  with  the  value 
"audible_alarm"  sounds  an  audible  alarm  in  the  terminal.  Update  with  the  value  "visual_alarm"  generates  a 
visual  indication  of  a  signal  from  the  application.  All  other  values  have  no  effect. 


8.3.14.3       Sequenced  Terminal  CO 

This  Control  Object  is  defined  in  7.3.  It  has  CO-category  "integer."  It  is  updated  by  the  Update  ST  CO  FER. 
and  may  be  used  to  communicate  uninterpreted  keystrokes  to  the  application. 


8.3.14.4       Unsequenced  Terminal  CO 

This  Control  Object  is  defined  in  7.4.  It  has  CO-category  "integer."  It  is  updated  by  the  Update  UT  CO  FER 
and  is  used  to  communicate  uninterpreted  keystrokes  to  the  application  urgently. 


8.3.15      Profile  Notes 


8.3.15.1       Definitive  Notes 

1 .  The  WT  control  object  provides  a  mechanism  for  the  application  VT-user  to  specify  a  time  in  which 
all  the  fields  of  a  form  must  be  completed.  The  terminal  VT-user  starts  the  timer  at  the  time  when 
it  receives  WAVAR.  If  the  timer  expires,  further  entry  by  the  device  is  stopped,  all  undelivered 
updates  are  transmitted,  and  WAVAR  is  relinquished.  The  undelivered  updates  are  transmitted 
followed  by  an  update  to  this  control  object.  The  WT  update  is  made  using  the  current  value  of  the 
WT  control  object.  The  device-control-object  VTE-parameter  is  used  to  link  this  CO  to  the  input 
device  that  it  controls.  The  data  element  of  this  CO  specifies  the  waiting  time  in  seconds.  A  zero 
value  signifies  that  a  Form  Waiting  Time  is  not  to  be  used.  The  initial  value  of  this  data  element  is 
zero. 

2.  If  there  are  two  or  more  Character-oriented  FEIs  of  the  same  type  associated  with  the  same  field, 
they  are  equivalent  to  a  single  FEI  of  that  type  whose  parameter  is  the  concatenation  of  the 
individual  parameter  values. 
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The  following  parameteric  FEIs  and  FECs  defined  in  clause  8.3.4  test  equality  of  characters: 

Allowed  First  Characters  FEI 
Allowed  Characters  FEI 
Disallowed  Characters  FEI 

Allowed  String  Values  FEI  I 
Allowed  Numeric  Values  FEI 

At  Characters  FEC  \ 

The  characters  for  each  such  FEI  or  FEC  are  specified  by  a  parameter  that  includes  an  optional  set 
of  secondary  attributes.  If  this  set  is  included,  the  test  is  on  both  prirnary  and  secondary  attributes; 
otherwise  it  is  on  primary  attributes  only.  If  the  test  is  on  primary  attributes  only,  then  characters 
which  pass  the  test  are  allowed,  disallowed  or  accepted,  as  appropriate,  irrespective  of  the  values 
of  their  secondary  attributes.  The  set  of  secondary  attributes  need  not  specify  an  explicit  value  for 
every  secondary  attribute;  in  particular  the  empty  set  is  permissible.  Default  values  are  used  for  | 
unspecified  secondary  attributes.  These  are  determined  in  accordance  with  Definitive  Note  4.  | 

4.  .     The  parameter  values  for  a  number  of  FEIs,  FECs  and  FERs  require  default  values  to  be  used  for 

secondary  attributes  when  such  values  are  not  specified  explicitly  by  the  parameter.  The  first  choice 
default  for  each  secondary  attribute  value  is  the  field  modal  attribute  value  at  the  time  that  the  FEI, 
FEC  or  FER  is  accessed.  A  first  choice  default  value  of  "null"  is  resolved  as  specified  in  19.2.3.1  of 
ISO  9040  for  the  LOGICAL-TEXT  update  operation. 

5.  When  the  Character  oriented  FEIs  associated  with  a  particular  field  have  characters  in  common,  the 
precedence  algorithm  given  below  is  used. 

The  Allowed  First  Characters  FEI  takes  precedence  over  the  Allowed  Characters  and  Disallowed 
Characters  FEIs  for  field  character  position  l<=1.The  Disallowed  Characters  FEI  takes  precedence 
over  the  Allowed  Characters  FEI  for  all  field  character  positions. 

The  following  example  illustrates  the  conflict  resolution  algorithm.  When  a  particular  field  is  linked 
to  the  following  three  Character  oriented  FEIs: 


the  field  must  be  entered  with  the  letter  "a"  in  the  first  character  position  of  the  field.  The  remaining 
character  positions  in  the  field  are  limited  to  containing  the  letter  "b."  Therefore  field  entry  would 
be  limited  to  a  form  such  as  "abbbb.  ..." 

6;  The  following  syntax  and  semantics  is  mandatory  for  the  emphasis  and  device-emphasis  VTE- 
parameters.  The  scheme  of  B.I 7.3  of  ISO  9040  is  to  be  adopted  except  that  the  maximum  length 
for  an  ASN.1  PrintableString  used  as  an  emphasis  value  is  increased  from  6  characters  to  8 
characters.  Values  "B"  (Boxed)  and  "C"  (Encircled)  are  deleted  from  subattribute  "b."  Two  further 


Allowed  First  Characters 
Allowed  Characters 
Disallowed  Characters 


=  a,b 


=  a 


=  a 
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subattributes  are  added,  denoted  by  "g"  and  "h."  The  table  of  allowed  character  values,  ISO  6429 
SET  GRAPHIC  RENDITION  parameter  values  and  associated  semantics  given  in  B.I  7.3  of  ISO  9040 
is  augmented  by  the  addition  of: 


Subattribute  "g"  values 


  II  I  II 

=  "U"  * 


3 

23 


Subattribute  "h"  values 

=  "F"  51 
=  "C"  52 
=  "N"  *  54 


Italicized  characters 
Upright,  not  italicized 
characters 
No  change 


Framed 
Encircled 

Not  framed,  not  encircled 
No  change 


As  in  B.I 7.3  of  ISO  9040,  *  indicates  the  value  which  is  the  explicit  modal  default  value  for  the 
subattribute.  Not  all  the  values  of  this  scheme  need  to  have  a  1-1  correspondence  with  emphasis 
levels  available  on  the  real  device.  The  device  object  defines  the  real  mapping. 

7.  When  default  values  are  defined  for  a  multiple-occurrence  profile  argument  and  fewer  occurrences 
are  negotiated  than  are  required  by  the  value  of  a  parent  VTE-parameter,  the  remaining  occurrences 
still  take  the  specified  default  values. 


8.  Every  action  corresponding  to  the  operation  of  an  object  updating  device  shall  be  assigned  a  non- 
negative  integer  value.  This  value  shall  be  interpreted  as  a  logical  keystroke  in  accordance  with  the 
definitions  of  the  Sequenced  Terminal  CO  and  Unsequenced  Terminal  CO  in  7.3  and  7.4. 


Values  in  the  range  0-255  are  used  to  generate  entry  of  characters  into  the  Display  Object  from  the 
available  repertoires.  Values  greater  than  255  generate  the  Logical  Keystroke  FEE  and  thus  have 
effects  that  are  under  the  control  of  the  FEPCOs  present  in  the  VTE. 


9.  A  minimum  set  of  local  actions  is  defined  within  this  profile,  but  implementors  may  extend  this  as 
required.  A  host  implementation  thus  may  not  know  what  local  action  is  being  over-ridden  when 
it  requests  that  a  particular  logical  keystroke  should  be  notified  to  the  host.  To  prevent  this  from 
limiting  the  capabilities  of  the  terminal,  two  keystroke  combinations  that  differ  only  in  the  inclusion 
or  otherwise  of  the  ALT  key  are  required  to  have  the  same  potential  local  action.  Host 
implementations  are  advised  not  to  over-ride  the  action  of  both  such  keystrokes. 

The  defined  minimum  set  of  local  actions  concerns  control  of  the  current  entry  location.  At  any  time 
when  the  terminal  possesses  the  WAVAR  access  right,  there  is  a  well-defined  Display  Object  array 
element  which  is  the  current  candidate  for  update  by  a  character  entry  operation,  as  described  in 
Informative  Note  4.  If  this  element  lies  outside  of  any  field,  or  within  a  protected  field,  update  is 
prohibited  unless  the  negotiated  value  of  the  VTE-parameter  access-outside-fields  is  "yes,"  but  the 
array  element  is  still  defined.  Neither  this  location  nor  that  of  any  cursors  which  the  implementation 
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may  use  to  indicate  such  elements  is  recorded  In  the  CCA.  It  is  separate  from  the  current  position 
of  either  the  display  pointer  or  the  logical  pointer,  and  movement  of  this  entry  location  is  a  purely 
local  action. 


Table  12  -  Local  Actions  that  move  entry  location 


Name 

Unshifted  Action 

Shifted  Action 

lef tArrow 

X  =  x-1 

k  =  k-1 

right Arrow 

X  =  x+1 

k  =  k+1 

upArrow 

y  =  y-1 

f  s  f-1,  k  =  1 

downArrow 

y  =  y+1 

f  =  f+1,  k  =  1 

home 

(x,y,z)  =  "start-y" 

(k,f,z)  =  "start-k" 

end 

(x,y,z)  =  "end-y" 

(k,f,z)  =  "end-k" 

pageUp 

z  =  z-1,  x=l,  y=l 

z=z-l,  f=l,  k=l 

PageDown 

z  =  z+1,  x=l,  y=l 

z  =  z+1,  f  =  1,  k  =  1 

tab 

f  =  next(f),  k  =  1 

backTab 

f  -  previous(f),  k  =  1 

The  names  given  in  the  first  column  of  Table  12  are  the  identifiers  of  named  integers  of  type 
STCO.Key.  The  ASN.1  module  STCO  is  defined  as  part  of  the  specification  of  the  Sequenced 
Terminal  Control  Object  in  7.3.  These  identifiers  or  the  corresponding  integers  are  used  to 
designate  the  local  actions  specified  in  the  second  column.  If  the  initial  lower  case  letter  of  such 
a  name  is  converted  to  upper  case  and  prefixed  with  "shift"  then  it  designates  the  local  action 
specified  in  the  third  column. 

In  this  table,  "="  is  used  as  an  assignment  operator.  The  unshifted  actions  reference  array  elements 
by  normal  (x,  y,  z)  coordinates  while  the  shifted  actions  reference  them  by  logical  (k,  f,  z) 
coordinates.  The  values  next(f)  and  previous(f)  are  defined  in  19.1.3.2.2  of  ISO  9040,  "start-k"  and 
"end-k"  are  defined  in  19.1.3.5,  and  "start-y"  and  "end-y"  are  defined  in  19.1.1.4  of  ISO  9040. 

If  the  initial  or  final  coordinate  values  are  undefined  then  the  local  action  is  implementation- 
dependent.  However,  a  host  implementation  can  use  the  mandatory  FEPCO  to  control  the  behavior 
in  such  circumstances.  Field  Entry  Conditions  are  provided  to  test  whether  a  particular  local  action 
would  make  the  entry  location  leave  the  current  field  or  navigation  path,  as  defined  in  8.3.10. 

10.  If  the  VTE-parameter  access-outside-fields  takes  the  value  "allowed",  when  data  entry  terminates, 
the  display  pointer  shall  be  aligned  with  the  current  entry  location  by  an  explicit  or  implicit 
addressing  operation.  In  this  way,  the  value  of  the  display  pointer  notifies  the  application  of  the 
current  entry  location. 
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11.  Use  of  the  values  "F"  (Framed)  and  "C"  (Encircled)  for  emphasis  subattrlbute  "h"  causes  groups  of 
characters  within  a  single  field  which  have  this  subattrlbute  value  to  be  outlined  by  a  frame.  The 
two  subattributes  differ  only  in  that  the  external  corners  of  the  frame  are  squared  if  value  "F"  is  used 
and  rounded  if  value  "C"  is  used.  An  external  corner  is  where  two  lines  meet  in  a  L  shape,  as 
distinct  from  a  T  junction  and  from  the  intersection  of  two  lines.  The  nature  of  the  external  corner 
is  controlled  by  the  subattrlbute  value  of  the  array  element  on  the  inside  of  the  corner. 

More  precisely,  a  character  box  element  is  defined  to  be  within  frame  (f,z)  if  It  is  in  the  field  with 
coordinates  (f,2)  and  has  either  the  framed  or  encircled  attribute.  A  character  box  element  is 
defined  to  be  without  frame  if  either  it  is  not  in  any  field  or  it  does  not  have  either  the  framed  or 
encircled  attribute.  In  the  image  of  a  y-array  on  the  real  device,  a  line  is  drawn  between  two 
adjacent  images  of  character  box  elements  if  they  are  within  different  frames,  or  if  one  is  within  a 
frame  and  one  Is  without  frame.  In  addition  if  a  character  box  element  is  within  some  frame,  a  line 
is  drawn  along  any  edge  of  that  element  which  is  not  in  common  with  any  other  character  box 
element,  i.e.,  along  any  edges  which  are  part  of  the  image  of  the  boundary  of  the  Display  Object. 


8.3.15.2       Informative  Notes 

1.  Updates  by  the  application  VT-user  (only  possible  within  the  z-window)  are  not  necessarily 
immediately  imaged  to  the  (human  user  of  the)  terminal  VT-user  unless  the  real  window  of  the 
device  is  currently  positioned  over  such  an  update.  Such  updates  may  move  the  real  window  if  a 
VT-DELIVER  indication  is  received. 

When  WAVAR  is  relinquished  by  the  application  VT-user  the  window  may  be  moved  so  that  the  field 
addressed  by  the  CCO  is  within  the  window. 

Application  VT-user  addressing  operations  that  advance  z  to  a  higher  address  which  is  outside  of 
the  z-window  cause  the  z-window  to  move  and  include  one  or  more  new  y-arrays  for  which  no  fields 
are  defined.  As  the  z-window  moves,  one  or  more  y-arrays  at  lower  addresses  will  no  longer  be 
included  in  the  z-window.  The  field  definition  records  for  such  y-arrays  are  implicitly  deleted. 

2.  Several  of  the  descriptions  of  Field  Entry  Instructions  refer  to  'empty'  array  elements  of  the  Display 
Object.  This  is  to  be  interpreted  in  the  sense  of  13.2  of  ISO  9040.  Note  that  in  this  sense  an  array 
element  containing  a  space  character  is  not  empty.  The  representation  of  an  empty  array  element 
on  the  real  device  is  implementation-dependent,  but  for  this  reason  it  is  recommended  that  the 
representation  used  should  be  distinct  from  that  of  a  space  character. 

3.  The  descriptions  of  a  number  of  Field  Entry  Conditions  refer  to  the  current  field  and  to  the  current 
location  for  the  next  character  entry.  Typically  this  current  location  will  be  indicated  to  the  human 
user  by  a  visible  cursor.  When  this  location  lies  within  a  defined  field,  that  field  is  the  current  field 
and  the  Entry  Invoke  Character  FEI  may  be  used  to  specify  the  nature  of  the  visible  cursor. 
However,  a  terminal  implementation  may  allow  the  visible  cursor  to  be  moved  outside  of  any  defined 
field.  While  this  is  so,  the  representation  of  the  cursor  is  implementation  dependent,  the  current  field 
Is  undefined  and  no  FEPRs  are  active. 
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8.3.18 


Specific  Conformance  Requirements 


For  further  agreement. 


8.4 


X3  Profile 


0!W  VTE-Profile  X3-1989  ( r1,  r2,  r3.  r4,  r5.  r6  ) 


8.4.1 


Introduction 


This  profile  provides  support  for  CCITT  X.3  PAD  compatible  operation. 
The  purpose  of  this  profile  is  two-fold: 

-  to  provide  a  transitional  environment  for  applications  that  assunne  the  availability  of  X.3 
parameters  with  which  to  control  the  behavior  of  the  terminal-system. 

-  to  facilitate  a  gateway  function  between  ISO-VTP  and  X.3. 

8.4.2  Association  Requirements 

8.4.2.1  Functional  Units 

The  Structured  CO  Functional  Unit  is  mandatory. 
The  Urgent  Data  Functional  Unit  is  optional. 

8.4.2.2  Mode 

This  is  an  A-mode  profile. 

8.4.3  Profile  Body 

Display-objects  = 


{ 
{ 
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display-object-name  =  D1, 

DO-access  =  profile-argument-r1 , 

dimensions  =  "one," 

x-dimension  = 
{ 

x-bound        =  "unbounded," 
x-addressing  =  "not-permitted," 
x-absolute      =  "no," 
x-window       =  0 

}. 

repertoire-assignment  =  <ESC>  2/5  2/15  4/2 

*(  VTS  Transparent  Set  )* 

}. 

{ 

display-object-name  =  D2, 

DO-access  =  opposite  of  profile-argument-r1 , 

dimensions  =  "one," 

x-dimension  = 

{ 

x-bound        =  "unbounded," 
x-addressing  =  "not-permitted," 
x-absolute      =  "no," 
x-window       =  0 

}, 

repertoire-assignment  =  <ESC>  2/5  2/15  4/2 

*(  VTS  Transparent  Set  )* 

}, 

}. 

Control-objects  = 
{ 

{  *(  PAD  - 

Each  element  of  the  PAD  CO  represents  a  CCITT  PAD  parameter.  The  CO-element-id 

of  each  element  has  been  chosen  so  that  it  would  be  the  same  value  as  the  CCITT  PAD 

parameter  number  that  it  represents.  The  PAD  CO  is  used  both  to  set  CCITT  PAD 

parameter-equivalent  values  and  to  reply  to  an  update  to  the  READ  CO.  See  Definitive 

Note  25  for  conventions  concerning  updates  to  this  CO.  )* 

co-name      =  PAD, 

co-structure  =  22, 

co-access     =  "NSAC," 

CO-priority     =  "normal," 

CO-trigger      =  "not-selected," 

{        *(  X.3  parameter  1  -  PAD  recall  )* 
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CO-element-id         =  1, 
CO-category  =  "transparent," 

co-size  =  8  }, 

{        *(  X.3  parameter  2  --  PAD  echo  )* 
CO-element-id         =  2, 
CO-category  =  "boolean," 

co-size  =  1  }, 

{  *(  X.3  parameter  3  -  Data  Forwarding  Character  )* 
CO-element-id  =  3, 

CO-category  =  "boolean," 

CO-size  =  7  }, 


I 


! 
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{        *(  X.3  parameter  4  --  Idle  Timer  Delay  )* 

CO-element-id          =  4, 

CO-category  =  "integer," 

co-size  =  255  }, 

{        *(  X.3  parameter  5  --  Ancillary  Device  Control  )* 

CO-element-id  =  5, 

CO-category  =  "boolean," 

CO-size  =  1  }, 

{        *(  X.3  parameter  6  -  Control  of  PAD  Signals  )* 

CO-element-id          =  6, 

CO-category  =  "transparent," 

co-size  =  4  }, 

{        *(  X.3  parameter  7  -  PAD  action  on  receipt  of  Break  )* 

CO-element-id          =  7, 

CO-category  =  "boolean," 

CO-size  =  5  }, 

{        *(  X.3  parameter  8  ~  Discard  Output  )* 

CO-element-id         =  8, 

CO-category  =  "boolean," 

CO-size  =  1  }, 

{        *(  X.3  parameter  9  ~  Padding  After  <CR>  )* 

CO-element-id         =  9, 

CO-category  =  "integer," 

CO-size  =  7  }, 

{        *{  X.3  parameter  10  --  Line  Folding  )* 

CO-element-id         =  10, 

CO-category  =  "Integer," 

co-size  =  255  }, 

{        *(  X.3  parameter  1 1  -  Device  Speed  )* 

CO-element-id  =11, 

CO-category  =  "symbolic," 

CO-category  =  19  }, 

{        *(X.3  parameter  12  ~  Flow  Control  by  Device  )* 

CO-element-id  =  12, 

CO-category  =  "boolean," 

CO-size  =  1  }, 

{        *(  X.3  parameter  13  -  Insert  <LF>  after  <CR>  )* 

CO-element-id         =  13, 

CO-category  =  "boolean," 

CO-size  =  3  }, 

{        *(  X.3  parameter  14  ~  Linefeed  Padding  )* 

CO-element-id         =  14, 

CO-category  =  "integer," 
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co-size  =  7  }, 

*{  X.3  parameter  15  --  Editing  )* 

CO-element-id         =  15, 

CO-category  =  "boolean," 

co-size  =  1  }, 

*{  X.3  parameter  16  -  Character  Delete  )* 

CO-element-id         =  16, 

CO-category  =  "character," 

CO-repertoire-assignment    *(  any  from  CO  )* 

=  "void,"  "void,"  <ESC>  2/1  4/0, 
co-size  =  1  }, 

*(  X.3  parameter  17  --  Line  Delete  )* 
CO-element-id         =  17, 
CO-category  =  "character," 

CO-repertoire-assignment  *(  any  from  CO  )* 

=  "void,"  "void,"  <ESC>  2/1  4/0, 
co-size  =  1  }, 

*(  X.3  parameter  18  -  Line  Display  )* 
CO-element-id  =  18, 

CO-category  =  "character," 

CO-repertoire-assignment  *{  any  from  CO  )* 

=  "void,"  "void,"  <ESC>  2/1  4/0, 
CO-size  =  1  }, 

*{  X.3  parameter  19  -  Editing  Service  Signals  )* 
CO-element-id  =  19, 

CO-category  =  "transparent," 

CO-size  =  8  }, 

*{  X.3  parameter  20  -  Echo  Mask  )* 
CO-element-id         =  20, 
CO-category  =  "boolean," 

CO-size  =  8  }, 

*{  X.3  parameter  21  --  Parity  Treatment  )* 
CO-element-id         =  21, 
CO-category  =  "boolean," 

CO-size  =  2  }, 

*(  X.3  parameter  22  --  Page  Wait  )* 
CO-element-id         =  22, 
CO-category  =  "integer," 

CO-size  =  256  } 


{  *(  READ  - 
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Each  boolean  of  the  READ  CO  represents  an  elennent-id  of  the  PAD  CO  with  the  same 
identifying  value.  The  READ  CO  is  used  to  request  the  current  values  of  PAD  CO,  which 
may  have  been  changed  by  some  local  agent.  See  the  description  of  the  PAD  CO  for 
how  the  update  to  this  CO  modifies  the  access  to  the  PAD  CO.  )* 
CO-name       =  READ, 
CO-structure  =  1, 

CO-access     =  opposite  of  profile-argument-rl , 

CO-priority     =  "normal," 

CO-trigger      =  "not-selected," 

CO-category  =  "boolean," 

co-size        =  22 

}. 

{  *(  Break  Out-of-Band  - 

receipt  of  this  control  object  represents  "X.25  Interrupt";  use  is  applicable  when  boolean 

1  of  element-id  7  in  PAD  CO  has  the  value  "true."  )* 

CO-name       =  BO, 

CO-structure  =  1, 

CO-access     =  profile-argument-r1 , 

CO-priority     =  "urgent," 

CO-trigger      =  "not-selected," 

CO-category  =  "symbolic," 

co-size        =  1 

}, 

{  *(  Break  In-Band  - 

receipt  of  this  control  object  represents  "indication  of  break";  use  is  applicable  when 

boolean  3  of  element-id  7  in  PAD  CO  has  the  value  "true."  )* 

CO-name      =  Bl, 

CO-structure  =  1, 

CO-access     =  profile-argument-r1 , 

CO-priority     =  "normal," 

CO-trigger      =  "selected," 

CO-category  =  "symbolic," 

CO-size        =  1 
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{  *(CUD- 

This  CO  is  used  to  optionally  convey  Call  User  Data  which  is  normally  carried  in  the 
CCITT  PAD  call.  The  CO  is  not  updatable,  but  may  be  given  initial  content  value  by 
special  profile  arguments  r2  and  r3.  The  CO  is  parametric,  with  two  elements,  one 
representing  the  protocol  identifier  field,  and  the  other  representing  the  call  data  field 
containing  user  data.  )* 
co-name       =  CUD, 
CO-structure  =  2, 
CO-access     =  "no-access," 
{        *(  Protocol  Identifier  )* 
CO-element-id  =  1, 
CO-category  =  "character," 
CO-repertoire-assignment  *(  VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
co-Size         =  4  }, 
{        *(  User  Data  )* 
CO-element-id  =  2, 
CO-category  =  "character," 
CO-repertoire-assignment  *(VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
co-size         =  124  } 
}. 

{  *(  DTE  - 

This  CO  is  used  to  optionally  indicate  the  calling  and  called  DTE  addresses  which  are 

normally  available  in  a  true  CCITT  PAD  environment.  They  may  not  be  updated,  but  may 

be  given  initial  content  values  by  special  profile  arguments  r4  and  r5.  )* 

CO-name       =  DTE, 

CO-structure  =  2, 

CO-access     =  "no-access," 

{        *(  Calling  DTE  address  )* 

CO-element-id         =  1, 

CO-category  =  "character," 

CO-repertoire-assignment  *(VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 

co-size  =  15  }, 

{        *(  Called  DTE  address  )* 

CO-element-id  =  2, 

CO-category  =  "character," 

CO-repertoire-assignment  *(\/TS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 

co-size  =  15  } 


64 


PART  14  -  VIRTUAL  TERMINAL 


December  1990  (Stable) 


{  *(  FAC  - 

This  CO  is  used  to  optionally  indicate  the  CCITT  facilities  which  are  nornnally  negotiable 
during  the  establishment  of  a  PAD  virtual  circuit.  The  negotiation  takes  place  via  special 
profile  argument  r6,  where  the  initiator  may  propose  the  initial  content  value,  and  the 
acceptor  may  return  other  values.  )* 
co-name       =  FAC, 
CO-structure  =  1, 
CO-access     =  "no-access," 
CO-category  =  "character," 
CO-repertoire-assignment  *(VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
co-size         =  127 


Device-objects  *(double  occurrence)*  = 
{ 

{ 

device-name  =  DEVICE-1, 
device-default-CO-access  =  profile-argument-rl , 
device-default-CO-priority  =  "normal," 
device-default-CO-trigger  =  "not-selected," 
device-default-CO-initial-va!ue  =  1."true," 
device-minimum-X-array-length  =  1,*(no  constraint)* 
device-control-object  =  {  Bl,  BO,  PAD  }, 
device-display-object  =  D1 

*(termination  parameters  are  controlled  explicitly  through  the  values  assigned  to  elements 

3  and  4  of  the  PAD  Control  Object)* 

}. 

{ 

device-name  =  DEVICE-2, 

device-default-CO-access  =  opposite  of  profile-argument-rl , 
device-default-CO-priority  =  "normal," 
device-default-CO-trigger  =  "not-selected," 
device-default-CO-initial-value  =  1  ."true," 
device-minimum-X-array-length  =  1,  *(no  constraint)* 
device-control-object  =  {  READ,  PAD  }, 
device-display-object  =  D2 

} 

}. 

Type  of  delivery  control  =  "simple-delivery-control." 
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8^4.4       Profile  Arguments  * 

r1  -  is  mandatory,  and  is  used  to  establisli  the  access  rules  for  the  display  objects  and  several  of  the 
control  objects.  If  the  terminal-system,  i.e.,  that  which  includes  the  equivalent  of  the  PAD  function, 
establishes  the  VTE-profi!e  then  the  value  of  r1  should  be  "WACI".  If  the  system  not  including  the 
PAD  function  establishes  the  VTE-profile  then  the  value  of  r1  should  be  "WACA".  This  argument 
takes  one  of  the  values  "WACI"  or  "WACA."  It  is  identified  by  the  identifier  for  DO-access  for  display 
object  D1 . 

r2  -  is  an  optional  special  profile  argument,  and  is  used  to  set  the  intial  content  value  of  element  1  of 
the  CUD  CO.  The  value  is  encoded  from  the  binary  form  to  the  ASN.1  type  PrintableString 
according  to  the  algorithm  described  in  Definitive  Note  24.  This  argument  is  assigned  the  identifier 

"Pp-1." 

r3  -  is  an  optional  special  profile  argument,  and  is  used  to  set  the  initial  content  value  of  element  2  of 
the  CUD  CO.  The  value  is  encoded  from  the  binary  form  to  the  ASN.1  type  PrintableString 
according  to  the  algorithm  described  in  Definitive  Note  24.  This  argument  is  assigned  the  identifier 
"Pp-2." 

r4  -  is  an  optional  special  profile  argument,  and  is  used  to  set  the  initial  content  value  of  element  1  of 
the  DTE  CO.  The  value  is  encoded  from  the  binary  form  to  the  ASN.1  type  PrintableString 
according  to  the  algorithm  described  in  Definitive  Note  24.  This  argument  is  assigned  the  identifier 
"Pp-3." 

r5  -  is  an  optional  special  profile  argument,  and  is  used  to  set  the  initial  content  value  of  element  2  of 
the  DTE  CO.  The  value  is  encoded  from  the  binary  form  to  the  ASN.1  type  PrintableString 
according  to  the  algorithm  described  in  Definitive  Note  24.  This  argument  is  assigned  the  identifier 
"Pp-4." 

r6  -  is  an  optional  special  profile  argument,  and  is  used  to  set  the  initial  content  value  of  the  FAC  CO. 
The  value  is  encoded  from  the  binary  form  to  the  ASN.1  type  PrintableString  according  to  the 
algorithm  described  in  Definitive  Note  24.  This  argument  is  assigned  the  identifier  "Pp-5." 


8.4.5       Profile  Notes 


8.4.5.1         Definitive  Notes 

1.       The  value  assigned  to  element  1  of  PAD  CO  selects  the  character  used  to  return  control  to  the 
terminal-system.  The  valid  values  and  associated  meanings  are: 
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Table  13  -  PAD  CO  data  element  1  value  definition 


value 

Meaning 

0 

not -permit ted 

1 

1/0  character  (DLE) 

32-126 

graphic  character 

The  value  assigned  to  element  2  of  PAD  CO  determines  whether  or  not  characters  are  echoed  at 
the  terminal-system.  When  the  value  of  this  boolean  is  "true,"  then  the  characters  are  echoed  at  the 
terminal-system. 

The  values  assigned  to  element  3  of  PAD  CO  control  the  forwarding  of  characters  from  the  terminal- 
system  to  the  application-system  based  on  the  character  value.  The  defined  booleans  and 
associated  meanings  are: 

Table  14  -  PAD  CO  data  element  3  value  definition 


boolean 

neaning 

1 

alphanumeric  (A-Z,  a-z,  0-9) 

2 

character  0/13  (CR) 

3 

characters  1/11  (ESC),  0/7  (BEL), 
0/5   (ENQ),   0/6  (ACK) 

4 

Characters  7/15  (DEL),  1/8  (CAN), 
1/2  (DC2) 

5 

characters  0/3  (ETX),  0/4  (EOT), 

6 

characters  0/9  (HT),  0/10  (LF), 
0/11   (VT),   0/12  (FF) 

r 

all  others  in  coliunn  0  and  1  not 
already  included  above 

The  value  assigned  to  element  4  of  PAD  CO  controls  the  fonwarding  of  characters  from  the  terminal- 
system  to  the  application-system  based  on  the  duration  of  idle  time  elapsed  between  consecutive 
characters  received  by  the  terminal-system  from  the  device.  The  valid  values  include  any  non- 
negative  integer  0-255;  a  value  between  1  and  255  indicates  the  time-out  in  twentieths  of  a  second; 
a  value  of  0  means  that  a  time-out  is  not  a  fonwarding  condition. 

The  value  assigned  to  element  5  of  PAD  CO  determines  whether  the  XON/XOFF  flow-control 
characters  (1  /I  and  1  /3)  are  available  for  use  by  the  terminal-system.  When  the  value  of  this 
element  is  "true,"  then  the  flow-control  characters  are  available,  and  the  terminal-system  may  use 
them  to  indicate  to  the  device  its  readiness  to  accept  characters  from  it. 
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6.  The  value  assigned  to  element  6  of  PAD  CO  determines  whether  the  terminal-system  issues 
messages,  called  PAD  service  signals,  to  the  device  during  the  association.  The  specific  service 
signals  are  not  a  part  of  this  profile  definition,  only  the  control  of  their  issue. 

7.  '    The  values  assigned  to  element  7  of  PAD  CO  determine  the  behavior  at  the  terminal-system  when 

a  Break  is  received  from  the  device.  The  defined  booleans  and  associated  meanings  are: 

Table  15  -  PAD  CO  data  element  7  value  definition 


boolean 

Bteaning 

1 

update  BO  CO 

2 

release  the  association 

3 

update  BI  CO 

4 

return  control  to  terminal-system 

5 

discard  data  from  application-system 

When  all  booleans  have  the  value  "false,"  there  is  no  action  at  the  terminal-system  when  a  Break  is 
received. 

A  useful  combination  of  booleans  with  value  "true"  is  (1 ,3,5).  When  a  Break  is  received,  the  terminal- 
system  updates  both  the  BO  CO  and  the  BI  CO  and  discards  all  display-object  updates  from  the 
application-system  until  it  receives  an  update  to  the  PAD  CO  for  element  8.  The  result  is  that  the 
data  path  has  been  cleared  in  both  directions.  Notice  that  this  is  non-destructive  of  control  object 
updates. 

8.  The  value  assigned  to  element  8  of  PAD  CO  determines  whether  or  not  the  terminal-system  discards 
data  from  the  application-system.  This  element  works  with  element  7  to  acknowledge  the  receipt 
of  the  Break  and  resume  normal  processing  of  display-object  updates.  The  only  valid  value  of  this 
boolean  in  an  update  is  "false." 

9.  The  value  assigned  to  element  9  of  PAD  CO  indicates  the  number  of  padding  cfiaracters  to  be 
generated  by  the  terminal-system  to  the  device  following  a  carriage  return  character.  The  valid 
values  are  integers  in  the  range  0-7. 

10.  The  value  assigned  to  element  10  of  PAD  CO  indicates  the  number  of  graphic  characters  sent  to 
the  device  after  which  the  terminal-system  will  insert  a  carriage  return.  The  valid  values  are  integers 
in  the  range  0-255,  where  a  value  of  0  means  that  this  function  is  not  performed. 

11.  The  value  assigned  to  element  11  of  PAD  CO  indicates  the  bit-transmission  speed  of  the  device. 
This  element  may  only  appear  in  an  update  sent  to  the  application-system  in  response  to  an  update 
of  the  READ  CO  when  boolean  1 1  has  the  value  "true." 
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12.  The  value  assigned  to  element  12  of  PAD  CO  determines  whether  the  XON/XOFF  flow-control 
characters  (1/1  and  1/3)  are  available  for  use  by  the  device.  When  the  value  of  this  element  is 
"true,"  then  the  flow-control  characters  are  available,  and  the  device  may  use  them  to  indicate  to  the 
terminal-system  its  readiness  to  accept  characters  from  It. 

13.  The  values  assigned  to  element  13  of  PAD  CO  determine  under  which  situations  a  linefeed  is 
inserted  following  a  carriage  return  character.  The  valid  values  and  associated  meanings  are: 

Table  16  -  PAD  CO  data  element  13  value  definition 


boolean 

■eaning 

1 

insert  linefeed  after  carriage 
return  sent  to  device 

2 

insert  linefeed  after  carriage 
return  received  from  device 

3 

insert  linefeed  after  carriage 
return  echoed  to  the  device 

14.  The  values  assigned  to  element  14  of  PAD  CO  determine  the  number  of  padding  characters 
generated  by  the  terminal-system  to  the  device  following  a  linefeed  character.  The  valid  values  are 
any  number  in  the  range  0-7. 

15.  The  value  assigned  to  element  15  of  PAD  CO  determines  whether  or  not  the  terminal-system 
performs  data-editing.  When  this  CO  has  value  "true,"  the  values  of  the  elements  3  and  4  of  the 
PAD  CO  are  ignored. 

16.  The  value  assigned  to  element  16  of  PAD  CO  determines  which  character  is  used  in  editing  the  line 
to  signify  the  function  "delete  character."  The  valid  values  are  the  IA5  characters,  decimal  value  0- 
127.  Only  applicable  if  the  value  of  element  15  of  PAD  CO  is  "true." 

17.  The  value  assigned  to  element  17  of  PAD  CO  determines  which  character  is  used  in  editing  to 
signify  the  function  "delete  line."  The  valid  values  are  the  IA5  characters,  decimal  value  0-127.  Only 
applicable  if  the  value  of  element  15  of  PAD  CO  is  "true." 

18.  The  value  assigned  to  element  18  of  PAD  CO  determines  which  character  is  used  in  editing  to 
signify  the  function  "display  line."  The  valid  values  are  the  IA5  characters,  decimal  value  0-1 27.  Only 
applicable  if  the  value  of  element  15  of  PAD  CO  is  "true." 

19.  The  value  assigned  to  element  19  of  PAD  CO  determines  whether  the  terminal-system  provides  for 
editing  of  PAD  service  signals.  The  valid  values  and  meanings  are  as  follows: 
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Table  17  -  PAD  CO  data  element  19  value  definitions 


value 

■eaning 

0 

no  editing 

1 

editing  as  for  a  paper  device 

2 

editing  as  for  a  glass  device 

8 

editing  using  one  editing  character 

32-126 

editing  using  one  editing  character 

20.  The  values  assigned  to  element  20  of  PAD  CO  determines  which  characters  are  NOT  to  be  echoed 
to  the  device  by  the  terminal-system.  If  no  bits  are  set,  then  all  characters  are  to  be  echoed, 
assuming  that  element  2  has  the  value  "true."  The  defined  booleans  and  associated  meanings  are: 


Table  18  -  PAD  CO  data  element  20  value  definition 


boolean 

mecming 

1 

Do  not  echo  0/13  (CR) 

2 

Do  not  echo  0/10  (LF) 

3 

Do  not  echo  0/11  (VT),  0/9  (HT),  0/12  (FF) 

4 

Do  not  echo  0/7  (BEL),  0/8  (BS) 

5 

Do  not  echo  1/11  (ESC),  0/5  (ENQ) 

6 

Do  not  echo  0/6  (ACK),  1/5  (NAK),  0/2  (STX), 
0/1   (SOH),   0/4   (EOT),   1/7   (ETB),   0/3  (ETX) 

7 

Do  not  echo  the  editing  characters  defined  by 
data  elements  16,  17,  and  18  of  the  PAD  CO 

8 

Do  not  echo  7/15  (DEL)  or  any  of  the  other 
characters  belonging  to  CO  or  CI  which  are 
not  already  mentioned  above 

21.  The  value  assigned  to  element  21  of  PAD  CO  determines  the  treatment  of  parity  on  the  characters 
received  from  and  sent  to  the  device  from  the  terminal-system.  The  defined  booleans  and 
associated  meanings  are: 
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Table  19  -  PAD  CO  data  element  21  value  definition 


boolecin 

Becming 

1 

parity  is  checked  on  characters 
received  from  the  device 

2 

parity  is  generated  on  characters 
sent  to  the  device 

22.  The  value  assigned  to  element  22  of  PAD  CO  determines  the  number  of  linefeeds  tliat  the  terminal- 
system  may  send  to  the  device  before  it  must  wait  for  input  from  the  device  to  request  it  to  continue 
displaying  characters.  The  range  of  valid  values  is  0-255,  where  a  value  of  0  indicates  that  the 
terminal-system  need  never  wait. 

23.  The  TEXT  operation  is  the  only  operation  allowed  on  the  display  objects. 

24.  Special  profile  arguments  r2-r6  have  binary  values.  However,  due  to  a  restriction  in  the  standards 
9040  and  9041,  those  binary  values  must  be  conveyed  in  the  ASN.1  type  PrintableString.  This  is 
accomplished  by  mapping  the  value  of  each  semi-octet  in  the  string  of  binary  octets  to  an  octet 
whose  value  falls  in  the  value  range  of  a  PrintableString.  The  semi-octet  values  in  the  range  0000  - 
1001  are  mapped  into  the  PrintableString  values  '0'  -  '9',  whereas  the  semi-octet  values  in  the  range 
1010  - 1 1 1 1  are  mapped  into  the  PrintableString  values  'A'  -  'F'.  The  result  is  a  string  of  characters 
which  is  exactly  twice  the  length  of  the  original  string  of  binary  octets. 

25.  The  value  of  CO-access  for  the  PAD  CO  is  "NSAC,"  however  a  convention  is  followed  that 
determines  when  a  VT-user  may  update  the  PAD  CO.  Only  the  VT-user  with  access  to  the  Display 
Object  D2  may  update  the  PAD  CO  except  immediately  after  it  has  updated  the  READ  CO.  When 
the  READ  CO  upidate  is  received  by  the  opposite  VT-user,  it  is  treated  as  a  request  to  update  the 
PAD  CO  with  the  parameter  values  it  is  currently  using,  at  which  point  that  VT-user  is  required  to 
respond. 


8.4.5.2        Informative  Notes 

1.  Users  of  this  profile  should  refer  to  CCITT  Recommendations  X.3,  X.28  and  X.29  for  the  original 
model  for  this  profile. 

2.  The  following  values  for  the  elements  of  the  PAD  CO  are  taken  from  the  CCITT  Simple  standard 
profile  and  may  prove  useful: 
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Table  20  -  CCITT  Simple  Standard  profile 


data  element 

value 

meaning 

1 

1 

possible  to  return  control  to 
terminal-system  using  0/1  (DLE) 

2 

l."true" 

echo  performed  at  the  terminal-system 

3 

1.  "false", 

2.  "true",  3. "true", 
4. "true",  5. "true", 
6. "true",  7. "true" 

forward  on  receipt  of  any  character  in 
CO  and  CI 

4 

0 

no  time-out  used  for  forwarding 
condition 

 ■  

5 

 — — ^ — 

1. "true" 

terminal-system  may  use  XON/XOFF  to 
flow-control  the  device 

6 

1. "true" 

service  signals  are  sent 

7 

2. "true",  all 
others  "false" 

release  the  association  when  a  Break 
is  received  from  the  device 

8 

1. "false" 

deliver  data  to  device 

9 

0 

do  not  pad  after  CR 

10 

0 

do  not  fold  the  line 

11 

read-only 

12 

1. "true" 

device  may  use  XON/XOFF  to  flow- 
control  the  terminal-system 

13 

0 

do  not  insert  LF  after  CR 

14 

0 

do  not  pad  after  LF 

15 

1. "false" 

do  not  edit  data 

16 

7/15  (DEL) 

character  delete 

17 

1/8  (CAN) 

line  delete 

18 

1/2  (DC2) 

line  display 

19 

1 

edit  as  for  paper 

20 

0 

echo  all  characters 

21 

0 

no  parity  checking  or  generation 

22 

0 

no  page  wait 

3.       The  following  values  for  the  elements  of  the  PAD  CO  are  taken  from  the  CCITT  Transparent  standard 
profile  and  may  prove  useful. 
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 Table  21  -  CCITT  Transparent  Standard  profile 


data  element 

value 

Beaning 

1 

0 

control  may  not  be  returned  to  the 
teriuinax— sys  r  em 

2 

1       fa  1  eo" 
X  «     L  ax  a 

rerminai— sysrem  aoes  not  pertorm 
character  echo 

o 
J 

aix  Dooxeans 
"false" 

no  forwarding  on  character  value 

4 

20 

forward  on  time-out  of  1  second 

5 

 —  

1. "false" 

terminal-system  may  not  flow-control 
the  device 

6 

1 . "false" 

service  signals  are  never  sent 

7 

2. "true",  all 
others  "false" 

release  the  association  when  a  Break 
is  received  from  the  device 

8 

1 . "false" 

deliver  data  to  device 

9 

0 

do  not  pad  after  CR 

10 

0 

do  not  fold  the  line 

11 

read-only 

12 

1 . "false" 

device  may  not  flow-control  the 
terminal-system 

13 

0 

do  not  insert  LF  after  CR 

14 

0 

do  not  pad  after  LF 

15 

1. "false" 

do  not  edit  data 

16 

7/15  (DEL) 

character  delete 

17 

1/8  (CAN) 

line  delete 

18 

1/2  (DC2) 

line  display 

19 

1 

edit  as  for  paper 

20 

0 

echo  all  characters 

21 

0 

no  parity  checking  or  generation 

22 

0 

no  page  wait 
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Annex  A  (normative) 
Specific  ASE  Requirements 

For  specific  ASE  Requirements  identified  by  the  Upper  Layer  SIG  for  Virtual  Ternninals,  see  Stable 
Implementation  Agreements  for  Open  Systems  Interconnection  Protocols:  Part  5  -  Upper  Layers. 
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Annex  B  (normative) 
Clarifications 

Defaults 

When  a  profile  argument  is  not  present  in  either  the  offer  or  vaiue  list,  the  default  for  the  corresponding  VTE 
parameter  is  specified  by  ISO  9040  if  it  is  not  given  by  the  argument  description  in  the  profile. 
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Annex  C  (normative) 
Object  Identifiers 

General  identifiers: 

oiw-vt  OBJECT  IDENTIFIER  ::  = 

{  iso(1)  identified-organization(3)  oiw(14)  vtsig(12)  } 

olw-vt-pr  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt  vteProfile(l)  } 

oiw-vt-co  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt  controlObject(O)  } 

oiw-vt-co-misc  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt-co     cotypennisc(0)  } 

oiw-vt-co-tcco  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt-co     cotypetcco(4)  } 

Profiles  defined  by  OIW  VT  SIG: 

oiw-vt-pr-telnet-1988  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt-pr     telnet-1 988(0)  } 

oiw-vt-pr-transparent-1988    OBJECT  IDENTIFIER  ::  = 
{  oiw-vt-pr     transparent-1 988(1)  } 

oiw-vt-pr-forms-1989  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt-pr     forms-1 989(2)  } 

0iw-vt-pr-x3-1989  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt-pr      x3-1 989(4)  } 

Control  Objects  defined  by  OIW  VT  SIG: 

oiw-vt-co-misc-sa  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt-co-misc       sa(0)  } 

oiw-vt-co-misc-ua  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt-co-misc       ua(1)  } 
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oiw-vt-co-misc-st 

{  oiw-vt-co-misc 

oiw-vt-co-misc-ut 

{  oiw-vt-co-misc 


OBJECT  IDENTIFIER  ::  = 

st(2)  } 

OBJECT  IDENTIFIER  ::  = 

ut(3)  } 
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NOTE  -  It  is  the  intent  of  the  National  Institute  of  Standards  and  Technology  (NIST)  Workshop  for 
Implementors  of  Open  Systems  Interconnection  (OSI)  to  move  into  this  part  the  Office  Document  Architecture 
(ODA)  document  application  profile  (DAP)  known  as  FOD36,  when  rt  is  approved  as  an  International 
Standardized  Profile  (ISP).  The  draft  text  for  the  proposed  Draft  ISP  has  been  submitted  to  the  ISO/IEC  Joint 
Technical  Committee  1,  Special  Group  on  Functional  Standards  (SGFS).  Refer  to  Part  16  of  the  Working 
Agreements  of  this  Workshop  for  the  current  version  of  this  text. 

This  replaces  previous  contents  of  this  part. 
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(ODA)  document  application  profile  (DAP)  known  as  FOD26,  when  it  is  approved  as  an  International 
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18  Network  Management 


0  Introduction 

Within  the  community  of  OSI  researchers,  users,  and  vendors,  there  is  a  recognized  need  to  address  the 
prot>lems  of  initiating,  terminating,  monitoring,  and  controlling  communication  activities  and  assisting  in  their 
harmonious  operation,  as  well  as  handling  abnormal  conditions.  The  activities  that  address  these  prob>lems 
are  collectively  called  network  management. 

Network  management  can  be  viewed  as  the  set  of  operational  and  administrative  mechanisms  necessary  to: 

a.  bring  up,  enroll,  and/or  alter  network  resources, 

b.  keep  network  resources  operational, 

c.  fine  tune  these  resources  and/or  plan  for  their  expansion, 

d.  manage  the  accounting  of  their  usage,  and 

e.  manage  their  protection  from  unauthorized  use/tampering. 

As  such,  network  management  is  typically  concerned  with  management  activities  in  at  least  the  following  five 
functional  areas:  configuration  management,  fault  management,  performance  management,  accounting 
management,  and  security  management.  In  order  to  accomplish  these  management  activities,  information 
must  be  exchanged  among  open  systems. 

In  Part  18,  there  are  Implementation  Agreements  (lA's)  for  providing  interoperable  OSI  management 
information  communication  services  among  OSI  systems.  Also  contained  here  are  agreements  on 
management  information.  These  agreements  pertain  to  the  exchange  of  management  information  and 
management  commands  between  open  systems  operating  in  a  multivendor  environment.  For  example,  one 
goal  is  to  ensure  that  a  management  system  built  by  one  vendor  can  manage  objects  built  by  another  vendor. 


1  Scope 

The  purpose  of  this  Part  (Part  18),  is  to  provide  implementation  agreements  that  will  enable  independent 
vendors  to  supply  customers  with  a  diverse  set  of  networking  products  that  can  be  managed  as  part  of  an 
integrated  environment.  Where  possible,  these  agreements  are  based  upon  OSI  Systems  Management 
standards. 
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1.1       Phased  Approach 

Because  of  the  broad  scope  of  the  subject,  and  given  that  OSI  Systems  Management  standards  are  still 
evolving,  it  is  reasonable  to  assume  that  a  comprehensive  set  of  network  management  implementation 
agreements  will  take  a  number  of  years  to  develop.  To  arrive  at  an  initial  set  of  implementation  agreements 
in  a  timely  fashion,  a  phased  approach  has  been  adopted. 

This  phased  work  approach  will  result  in  a  series  of  implementation  agreements  based  on  the  expanding  scope 
of  the  OSI  Systems  Management  standards.  It  is  the  intention  of  the  NMSIG  to  define  the  content  of  each 
phase  as  a  compatible  superset  of  the  previous  Phases  to  ensure  that  Phase  N  products  can  interact  with 
products  based  on  the  implementation  agreements  of  earlier  phases. 


1.1.1  Alignment  With  Evolving  Standards 

In  some  cases,  these  phased  implementation  agreements  may  be  based  on  DIS  standards.  As  the  relevant 
standards  progress  from  DIS  to  IS,  the  agreements  will  be  aligned  in  future  phases. 

When  a  defect  is  found  in  any  of  the  management  related  standards,  the  reported  defect  may  be  technically 
resolved  by  the  appropriate  international  technical  committee  with  likely  approval  by  the  voting  members 
pending  for  several  months.  Since  relevant  defects  can't  be  ignored  in  an  implementation,  these  agreements 
will  note  defect  resolutions  which  have  the  tentative  approval  of  the  appropriate  standards  committee.  These 
interim  resolutions  will  be  recorded  in  clause  4. 

Once  a  defect  resolution  has  been  completed  by  the  appropriate  standards  body,  the  agreed  upon  resolution 
will  be  incorporated  into  the  next  phase  of  these  implementors  agreements.  If  appropriate,  a  previous  phase 
that  relied  on  an  interim  resolution  will  be  examined  to  determine  whether  errata  should  be  issued  to  bring  the 
original  phase  into  line  with  the  final  resolution. 


1.1.2         Definition  of  Phase  1 

As  a  first  step  in  this  phased  approach,  the  NMSIG  has  targeted  an  initial  set  of  agreements  that  provide  limited 
interoperable  management  in  a  heterogeneous  vendor  environment.  They  are  the  beginning  of  a 
comprehensive  set  of  implementation  agreements  t)ased  on  the  emerging  OSI  Systems  Management 
standards.  Furthermore,  these  initial  agreements  allow  the  community  to  gain  experience  with  OSI 
management  standards  as  they  emerge. 

The  focus  of  the  Phase  1  agreements  is  to  enable  a  managing  process  provided  by  one  vendor  to  interoperate 
with  an  agent  process  provided  by  a  different  vendor  to  perform  limited  management  on  a  set  of  managed 
objects. 

The  scope  of  Phase  1  implementation  agreements  is  the  following: 
Management  Functions: 
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Object  Management  Function  [OMF], 

State  Management  Function  [STMF], 

Attributes  For  Representing  Relationships  [ARR], 

Alarm  Reporting  Function  [ARF], 

Event  Report  Management  Function  [ERMF]. 

Management  Information: 

Information  Model,  Naming,  Guidelines  and  Templates  for  Defining  Managed  Objects 
Management  Communication: 

CMIS/P,  Association  Policies,  and  Upper  Layer  Sen/ices  Required 
Management  Objects: 

Support  Objects  required  for  the  above. 

Editor's  Note:  [The  relation  of  the  MIL  definitions  in  Annex  A  of  the  Working  Document  to  Phase 
1  lA's  needs  to  be  clarified.] 

Conformance  Criteria: 

Conformance  Criteria  for  the  above  functionality. 

To  accomplish  these  goals  in  a  timely  fashion,  the  following  simplifying  constraints  have  been  reflected  in  the 
Phase  1  agreements: 

1.  No  agreements  are  provided  regarding  management  domains. 

2.  These  agreements  require  only  the  following  application  service  elements:  the  Association 
Control  Service  Element  (ACSE),  the  Common  Management  Information  Service  Element 
(CMISE),  Remote  Operations  Service  Element  (ROSE),  and  the  System  Management  Application 
Service  Element  (SMASE). 

3.  These  agreements  do  not  require  implementation  of  services  defined  by  the  Directory  standards. 

4.  No  agreements  regarding  the  security  of  management  are  provided. 


1.1.3         Future  Phases 

It  is  the  intention  of  the  NMSIG  to  freeze  the  content  of  Phase  1  when  these  agreements  are  progressed  to 
Stable  status.  Alignment  changes  required  as  the  standards  progress  from  DIS  to  IS  will  be  made  in  future 
phases. 
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As  standards  defining  new  functionality  are  progressed,  the  NMSIG  will  define  future  phases  incorporating  the 
new  functionality  as  a  compatible  superset  of  previous  phases. 


2      Normative  References 

The  following  documents  are  referenced  in  the  statements  of  the  agreements  relating  to  OSI  network 
management.  The  notation  indioatoo  that  tontativo  obicot  idontif ioro  oontainod  in  thooo  BIS  lovol  dooumontG 
arc  suporGodod  by  the  NMSIG  Phase  1  object  idontifioro  containod  in  Annex  B.2  of  thooo  agroomonto. 


[ACSEP] 

[ACSESl 

[ADDRMVPJ 
[ADDRMVS] 

iiiiiiTii 


ISO  8650,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Protocol 
Specification  for  the  Association  Control  Service  Element  (Revised  Final  Text  of  DIS  8650), 
ISO/IEC  JTC1  /SC21  N2327,  21  April  1 988. 

ISO  8649,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Service 
Definition  for  the  Association  Control  Service  Element  (Revised  Final  Text  of  DIS  8649), 
ISO/IEC  JTC1/SC21  N2326,  21  April  1988. 

ISO/IEC9596/DAD  2,  Common  Management  Information  Protocol  Specification:  Addendum 
2  (Add/Remove  Protocol),  ISO/IEC  JTC1/SC21, 1  February  1990. 

ISO/IEC  9595/DAD  2,  Common  Management  Information  Service  Definition:  Addendum  2 
(Add/Remove  Service),  ISO/IEC  JTC1/SC21, 1  February  1990. 


DISP  11183 
AOMnn  OS\ 

't,  Information  Teclinology 

Management  -  Management 

'  International  Standardized 
CommunicatltMis  Protocols  - 

Profife$ 
Fart  1: 

Specification 

of  ACSE,  Presentation  and  Session  Protocols  for  the  use  by  BOSE 

f^MT1] 


and  CMISE,  September  1991, 

DISP  11183-3,  Infornnation  Technology  -  tnternallonal  St«f?darc8zed  Profifes 
AOMnn  0$t  Management  ♦  Management  Cbmmunioatlonst  Protocols  *  Part  3: 
AOM11  -  Basic  Management  Communications,  September  1991, 


DISP  11183-2,  Information 
AOMnn  0${  Management  ^ 

Technology 
Management 

-  lr>ternational  Standardized 

Profiles 

Communications  Protocols  > 

^  Part  2: 

AOMia 

-  Enhanced  Management  Communications,  September  1991 

[ARFJi 


[ARR]* 


ISO/IEC  OlS  10164-4,  Information  Technology  -  Open  Systems  Interconnection  - 
Systems  Management  -  Part  4:  Alarm  Reporting  Function,  ISO/IEC  JTC1/SC21 
N48§86369,  JuneAugust  19,  1! 


ISO/IEC  OlS  10164-3,  Information  Technology  -  Open  Systems  Interconnection  - 
Systems  Management  -  Part  3:    Attributes  for  Representing  Relationships, 
ISO/IEC  JTC1/SC21  N48§76ia6,  JuneSeptember  1990|. 
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[ASN1]  ISO/IEC  8824,  Information  Technology  -  Open  System  Interconnection  - 

Specification  of  Abstract  Syntax  Notation  One  (ASN.1),  ISO/IEC  JTC1/SC21 
N4720,  30  April  1990. 

[BER]  ISO/IEC  8825,  Information  Technology  -  Open  Systems  Interconnection  - 

Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1), 
ISO/IEC  JTC1/SC21  N4721,  30  April  1990. 

[CANGETP]  ISO/IEC  9596/DAD 1 ,  Common  Management  Information  Protocol  Specification: 
Addendum  1  (CancelGet  Protocol),  ISO/IEC  JTC1/SC21,  1  February  1990. 

[CANGETS]  ISO/IEC  9595/DAD  1,  Common  Management  Information  Service  Definition: 
Addendum  1  (CancelGet  Service),  ISO/IEC  JTC1/SC21,  1  February  1990. 

[CMIP]  ISO/IEC  9596-1,  Information  Technology  -  Open  Systems  Interconnection  - 

Common  Management  Information  Protocol  Specification  -  Part  1 :  Specification, 
24  November  1990. 

[CMIS]  ISO/IEC  9595,  Information  Technology  -  Open  Systems  Interconnection  - 
Common  Management  Information  Service  Definition,  Common  Management 
Information  Service,  24  November  1990. 

[DMI]*  ISO/IEC  QIS  10165-2,  Information  Technology  -  Open  Systems  Interconnection  - 
Structure  of  Management  Information  -  Part  2:  Definition  of  Management 
Information,  ISO/IEC  JTC1/SC21  N4867e363,  JemAtiguit  1990|. 

[ERMFJi       ISO/IEC  Q\S  10164-5,  Information  Technology  -  Open  Systems  Interconnection  - 
Systems  Management  -  Part  5:  Event  Report  Management  Function,  ISO/IEC 
JTC1/SC21  N48606360,  JweAugust  1990|. 

[GDMO]*       ISO/IEC  QIS  10165-4,  Information  Technology  -  Open  Systems  Interconnection  - 
Structure  of  Management  Information  -  Part  4:  Guidelines  for  the  Definition  of 
Managed  Objects,  ISO/IEC  JTC1/SC21  N48626309,  4&^Jt»fies|i||i|  1990|. 

[ISPFRM]  ISO/IEC  TR  10000-1,  Information  Technology  -  Framework  and  Taxonomy  of 
International  Standardized  Profiles  -  Part  1:  Framework,  ISO/IEC  JTC1/SGFS 
N184,  9  February  1990. 

[ISPSRVC]  ISO/IEC  TR  8509,  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Service  Conventions,  TC97/SC16/1646. 

[LCF]  ISO/IEC  ©IS  10164-6,  Information  Technology  -  Open  Systems  Interconnection  - 

Systems  Management  -  Part  6:  Log  Control  Function,  ISO/IEC  JTC1/SC21 
N486S6361,  June  19901. 
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[MIM]  ISO/IEC  QIS  10165-1 ,  Information  Technology  -  Open  Systems  Interconnection  - 

Management  Information  Services  -  Structure  of  Management  Information  -  Part 
1:  Management  Information  Model,  ISO/IEC  JTC1/SC21  N§2§263$t,  June 
1990|. 

[OMF]*         ISO/IEC  OlS  10164-1 ,  Information  Technology  -  Open  Systems  Interconnection  - 
Systems  Management  -  Part  1:    Object  Management  Function,  ISO/IEC 
JTC1/SC21  N48§§||||,  .kJoeS^mber  19901. 

[SMO]*  ISO/IEC  DIS  10040,  Information  Technology  -  Open  Systems  Interconnection  - 
Systems  Management  Overview,  ISO/IEC  JTC1/SC21  N486§R6353,  46 
JuReAugust  I99^i. 

[STMF]*        ISO/IEC  QIS  10164-2,  Information  Technology  -  Open  Systems  Interconnection  - 
Systems  Management  -  Part  2:    State  Management  Function,  ISO/IEC 
JTC1/SC21  N4866||8|,  JufieSeptember  19901. 

3  Status 


As  of  September  I99t 

.  the  stefole  management  communlcattor 

1  agreements  in  clause 

8  dl  part  18  ard  dause 

7  Of  part 

13  t>ecame 

techrijcally  equivalent  to  DI$P  ill 83. 

The 

Dl$P 

rlgqrotte  $latement  of 

3.  TheNMSlG  Is  participating  Inthedev^opment  of  the 

iSP  and  Inrendsio  reference  directly  ISP 

1 1 183,  Parts  1  through  3,  and,  In  so  doing,  all  the  agreements  therein,  vrfien  l$f*  1118$  Is  approved.  Hile  ISP 
is  expected  to  b&  approved  in  Aprii,  1 932.  Only  editorial  modifications  are  &xpecl«t  to  occur  betwesen  ^  OISP 
^     ISP,  In  the  Interim,  please  r^erto  OISP  11  m  If  techhicd)  darlfication  h  requln^d. 

(Refer  to  the  Working  Implementation  Agreements  Document  for  additional  status  information.) 

4  Errata 

Editor's  Note:  [  "Defect  Report"  material  (including  applicability)  may  be  included  here.] 

The  following  tat>le  indicates  the  clause,  type,  and  reference  document  of  technical  errata  to  this  part. 
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Erratum 
No. 

Type  & 
Date 
Entered 

Referenced 
Document 

Clause 

Comment 

1 

Technical 
6/91 

NMSIG- 
91  /Oo 

6.4.5 

This  clause,  previously  clause  6.2.6, 
was  modified  and  moved  to  clause 
6.4.5  to  clarify  that  it  is  intended  as  a 
support  agreement  for  CM  IP  rather 
than  a  usage  agreement  for  CM  IS. 

1 

Alignment 
9/91 

NMSIG* 
91/1 10 
NMSIG- 

91/113 

1 

This  clause  has  been  updated  ti; 
reflect  alignment  changes  to  the 
relevant  base  standards  which  hav0 
lust  progressed  to  IS  as  of  August, 
1991. 

1 

fechnical 
9/91 

NMSIG^ 
91/161 

6.2.2.2 

Move  text  from  clause  5. 1.2 J  tq 
more  appropriate  clause  6.2.2.2  and 
clarify  required  support  for  minimal 
filter  complexity  to  align  with  the  DISP 
11183, 

1 

Technical 
9/9t 

NMSIG^ 

iiiiii: 

iii 

ISemove  unnecessary  restrictions  on 
sending  CM  IP  tUm  parameters. 

1 

AUgnment 
9/91 

NMSIG- 

ii/i 14 

6  1.1 

Change  reference  to  required 
application  context  support  to  align 
with  IS  version  of  |SMOp 

1 

Technical 
9/91 

NMSIG- 
|l/161 

6.3.ai 

Jlemove  dause  requiring  mandatory 
attribute  list  in  successful  set 
response  because  considered 
redundant  tntormation. 

1 

Alignmem 

NMS1G- 

Hiiso 

1 

Update  clause  to  reflect  ailgnmi^ 
changes  to  the  relevant  base 

9/91 

Standards  which  have  progressed  to 
IS  as  of  August,  1991. 

1 

Editorial 
9/91 

NMSIG- 

li:/^t:6:1: 

6.3.6  1 

Move  clause  6.3.6.1  to  more 
appropriate  location  at  clause  7jxS^ 
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5  Management  Functions  and  Services 


SA  Gonoral  Agroomonto 


 Conventions  Uood  In  SMF  Agroomonto 

Each  Systom  Managomont  Function  dofinos  a  sot  of  sorvioos  roforrod  to  in  this  document  as  "SMF  sorvicos". 
Agroomonts  portlnont  to  SMF  sorvicos  arc  provided  in  the  following  subclausos.  Eaoli  subolauso  contains  a 
series  of  tables,  as  follows. 

 For  each  System  Management  Function,  a  table  lists  the  SMF  services  encompassed  by  the  function, 

whether  each  SMF  service  is  currently  within  the  scope  of  these  agreements,  and  related  nDanagomont 
support  objoeto  (if  any).  Although  a  managomont  support  object  may  bo  related  to  a  SMF  service,  it 
nrvay  or  may  not  bo  required  to  provide  the  SMF  sorvico. 

^.  For  each  SMF  service,  a  normative  table  ref eronoos  text  agroomonts  which  constrain  the  usage  and /or 

value  of  the  associated  service  parameters.  Text  agroomonts  defined  elsewhere  in  this  document  arc 
referenced  by  clause  number.  The  lack  of  a  reforonoo  signifies  no  agreement  beyond  the  base 
standard. 

These  tables  include  codes  which  specify  parameter  usage  for  request,  indication,  response,  and  confirmation 
service  primitives.  These  codes,  defined  in  subolauso  1.8.3  of  these  agreements  (Classification  of 
Confornrxincc) ,  in  I  SO/I  EC  TR 1 0000  1  (Framework  and  Taxonomy  of  ISPs)  [I  SPFRM] ,  and  in  I  SO/I  EC  TR  8600  j 
(Service  Conventions)  [ISPSRVC],  are  repeated  here  for  reader  convenience: 


M  Mandatory 

Q  Optional 

G{p) — If  Condition  p  oxisto.  then  paramotor  io  mandatory;  othorwico,  tho 

paramotor  io  not  applicablo. 

X  Excluded 

\  Out  Of  Soopo 

In  thooo  agroomonto,  thio  moano  that,  for  tho  oorroopondlng  olomont. 

*  implomontationo  may  uco  It  outoido  tho  ooopo  of  thooo  agroomonts, 

*  oonformanoo  tooto  ohall  not  bo  provided  for  it, 

*  implomontationo  may  conform  to  other  agroomonto  where  it  is  required, 

*  no  requiromento  are  placed  on  either  transmitter  or  receiver  to  support 

*  receiver  actions  are  unspecified  when  present. 
 Not  Applicable 

 The  value  of  the  parameter  is  identieal  to  the  corresponding  paramotor  in 

the  interaction  described  by  tho  preceding  related  oorvico  primitive. 
U  The  use  of  tho  parameter  io  a  service  user  option. 
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In  addition,  tho  oonvontion  "A>  B"  is  uood  in  normatlvo  tabloo  to  Indlcato  both  tho  uoago  opoolflod  by  tho  baeo 
Gtandard  (A)  and  ttio  additional  conctraint  impoood  by  tiiooo  agroomontG  (B).  Ttile  oonvontion  io  intondod  to 
call  attention  to  agroomonts  whicii  modify  tho  uoago  of  a  sorvioo  paramotor. 

Unlooo  othofwico  notod,  conditional  paramotoro  (C)  ohall  bo  prooont  according  to  tho  oonditionc  doflnod  In 
[CMIS]  and  the  roforoncod  Syotcm  Managomont  Function  baoo  otandard. 


SA^i  General  Agroomonto  Rofcronood  By  Many  SMF  Sorviooo 

Tho  following  gonoral  agreements  pertain  to  some  or  all  of  the  System  Managenment  Function  servioos  dof  inod 
throughout  clause  6.  Normative  tables  for  each  SMF  service  reference  those  general  agroomonts  whoro 
applicable.  These  agreements  do  not  apply  to  SMF  soni/ioes  and  parameters  which  do  not  reference  thorn. 


6.1.2.1  Minimal  Filter  Complexity 

If  an  implementation  supports  Multiple  Object  Solection,  then  it  shall  minimally  support  AND  and  OR  with  a  sot 
of  two  filter  conditions  (which  shall  not  themselves  bo  AND  or  OR),  and  NOT.  In  addition,  tho  implomontatlon 
shall  support  tho  filter  conditions  Equality,  GreatorOrEqual,  LessOrEqual,  and  Present.  This  moans  that  a 
conforming  implementation  is  not  required  to  support  compounds  (AND  or  OR)  with  more  than  two  itoms,  and 
is  not  required  to  support  the  Substring  filter  condition.  Additional  filter  items  and  conditions  are  beyond  tho 
scope  of  thoco  agroomonts. 


6.1.2.2  Mode  Paramotor  Uoago 

All  SMF  Son/ices  mapped  to  CMIS  M  EVENT  REPORT,  M  ACTION,  and  M  SET  shall  allow  either  confirmod  or 
unconfirmed  Mode  to  be  specified  by  the  service  invoker.  Tho  choice  of  Mode  may  bo  oonstrainod  by  tho 
managed  object  claos  definition. 


Bz2  Object  Managomont  Function  Agroomonts 


^AA  General  Agroomonts 

Those  agreements  addreoo  the  following  SMF  oorviooo  defined  by  tho  objoot  managomont  standard  [OMF]: 
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Table  1 :  Scope  of  Agroomonts  Relating  to  SMF  Sorvlcos  Dofinod  by  the  Object 

Management  Standard  [OMF] 


Object  Management  SMF 
Sorvico 

Within  Scope  Of 
Agroomonts 

Rolatod  Management 
Support  Objects 

Object  Croation  Reporting 

Event  Forwarding 
Diooriminator 

UDjoci  ueietion  Hoporting 

Event  Forwarding 
Diocriminator 

Ne 

Object  Name  Change 
Reporting 

Event  Forwarding 
Diooriminator 

Attribute  Value  Change 
Reporting 

Event  Forwarding 
Discriminator 

PT  Create 

PT  Delete 

PT  Action 

Vac 

PT  Set 

Ynf>- 

PTGet 

Yrp. 

PT  Event 

Ydp. 

Event  Forwarding 
Diooriminator 

§.2.2  Object  Creation  Reporting 

This  Gubolauso  providoo  agroomonto  portinont  to  tho  Objoot  Croation  Reporting  SMF  sorvioo dofinod  by  ooction 
0.1.1  of  [OMF].  Rolovont  CMIS  agroomonto  dofinod  in  Dubciauoo  6.3.1  aro  ropoatod  horo  for  complotonoos. 

Table  2:  Agreements  On  Parameter  Usage  Pertinent  to  tho  Object  Croation 

Reporting  SMF  Service 


SMF  Object  Creation 

1  1  VV| 

SMF  Agroomonts 

CMtS 

Reporting  Paramotor 

Agroomonts 

Invoke  Identifier 

M 

MM 

Mode 

M 

6.1.2.2 
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SMF  Object  Creation 
wcporring  r*aromgtcf 

Virsrt 

1  f  W| 

1  IO|J 

SMF  Agroomonts 

CMIS 
AgrGGmGnis 

Managed  Objoot  Clacc 

M 

y 

&AS 

Managod  Qbjoot  Inotanoo 

M 

y 

&^ 

Objoot  Croation 

M 

&AS 

Evont  Timo 

y 

- 

&^ 

Croato  Information 

— Souroo  Indioator 

y 

6.3.1.1 

— Additional  Croato 
 Information 

y 

6.3.1.1 

Curront  TImo 

y 

&^ 

Evont  Roply 

G 

Erroro 

G 

&AA 

 Objoot  Deletion  Reporting 

This  subolauso  provldoc  agroomonto  portinont  to  tho  Objoot  Dolotlon  Roporting  SMF  sorvioo  dof  inod  by  soction 
9.1.2  of  [OMF],  Rolovant  CMIS  agroomonto  dofinod  in  subolauso  6.3.1  arc  ropoatod  horo  for  Gomplotonoss. 

Table  3:  Agroomonts  On  Parameter  Usage  Portinont  to  tho  Object  Dolotion 

Roporting  SMF  Service 


SMF  Object  Deletion 

1 1  W| 

P  g»r\ 

SMF  Agroomonts 

GM4S 
Agroomonts 

Roporting  Parameter 

Invoko  Idontifior 

M 

MM 

6^ 

Modo 

M 

6.1. 2.a 

Managod  Objoot  Claos 

M 

y 

6^ 

Managod  Objoot  Inotanoo 

M 

y 

&^ 

Objoot  Dolotion 

M 

6t4^ 

Evont  Timo 

y 

6tSt3 
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WIVII     WJ Wl WIIUI 1 

Reporting  Paramotor 

Agreomonts 

Doloto  Information 

— Souroo  Indicator 

y 

6.3.1.1 

— Additional  Doloto 
 lnfornr)ation 

y 

6.3.1.1 

Current  Timo 

y 

&A3 

Evont  Roply 

G 

Errors 

G 

&AA 

B^2A  Objoot  Name  Change  Reporting 

The  Object  Namo  Change  Reporting  SMF  sorvioe  Is  usod  by  tho  managod  systom  to  report  tho  ronaming  of 
a  managed  object  Instance  to  a  managing  system. 

Use  of  the  Object  Namo  Change  Reporting  SMF  service  Is  beyond  the  scope  of  these  agreements. 


 Attribute  Value  Change  Reporting 

This  subclause  provides  agroomontc  portinont  to  tho  Attribute  Value  Change  Reporting  SMF  service  dofinod 
by  soction  0.1  .^1  of  [OMF],  Rolovant  CMIS  agreomonts  dofinod  in  subclause  6.3.1  are  repeated  hero  for 
completeness. 


Table  4:  Agreomonts  On  Paramotor  Usage  Portinont  to  tho  Attribute  Value 

Change  Reporting  SMF  Service 


SMF  Attr  Value  Change 

0A£1 
1 1 

Pf>r\ 

SMF  Agreements 

CMIS 
Agreements 

Report  Parameter 

Invoko  Idontifior 

M 

MM 

&A 

Mode 

M 

6.1.2.2 

Managod  Objoot  Class 

M 

y 

&AS 

M 

y 

6^ 

Managod  Objoot  Inotanoo 

12 


PART  18:  Network  Management 


September  1991  (Stable) 


SMF  Attr  Value  Chango 

SMF  Agroomontc 

GMIS 

Report  Parameter 

AgroomontG 

Attribute  Valuo  Chango 

M 

Evont  Timo 

Attributo  Chango  Information 

— Attributo  Chango  Dofinition 

 Attributo  ID 

M 

- 

6.3.1.1 

 Old  Attr  Valuo 

y 

- 

6.3.1.1 

 Now  Attributo  Valuo 

M 

- 

6.3.1.1 

 Sourco  Indicator 

y 

6.3.1.1 

y 

6.3.1.1 

— Additional  Chango 
 Information 

Currant  Timo 

y 

&^ 

Evont  Roply 

G 

Erroro 

G 

&AA 

 PT  Croato 

Thio  Gubolauso  providoc  agroomontc  portinont  to  tho  PT  Croato  SMF  sorvioo  dofinod  by  ooctlon  0. 1 .6  of  [OMF] 
Rolovant  GMIS  agroomontc  dofinod  in  cubclauoo  6.3.6  arc  ropoatod  horo  for  complotonooG. 

Table  6:  AgroomontG  On  Parameter  UGago  Portinont  to  tho  PT  Croato  SMF 

Service 


SIVIF  PT- Croato  Parameter 

D.Ck£l 
1  IWU 

SIVIF  Agroomonts 

GM4S 

Agroomonts 

Invoko  Idontifior 

M 

6t4 

Managod  Objoot  Class 

M 

G 

6^ 

Managod  Objoot  Instanoo 

y 

G 

6.2.1,  6.3.6.1 
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SMF  PT-Croato  Paramotor 

D 

1  IWU 

P  g» » 

SMF  Agroomonts 

CMIS 
Agroomonts 

Support  Objoot  Inotanoo 

y 

AoooGO  Control 

y 

6^ 

Roforonoo  Object  Inotanoo 

y 

Attribute  Liot 

y 

G 

6.4.6,  6.3.5.2 

Current  Timo 

y 

Erroro 

G 

6.4.4,  6.3.6.2 

[1]  This  paramotor  shall  bo  includod  in  ALL  suocoss  Gonfirmations. 


Editor's  Note: — [It  is  unoloar  whothor  attributos  suoh  as  objoctClasG  and  ID  aro  pormittod  in  tho  Attribute 
List  paramotor  of  tho  PT  CREATE  roquost.  This  quootion  has  boon  oubmittod  to  ANSI 
X3T6.4.  Doponding  upon  tho  anowor.  it  may  bo  noooooary  to  add  an  agroomont  stating  that 
tho  Managod  Objoot  Class  and  Instanco  paramotors  ovorrido  any  valuos  providod  in  tho 
Attribute  List  paramotor  ] 

SAT   PT-Delete 

This  subolauso  provides  agroomonts  portinont  to  tho  PT  Doloto  SMF  sorvioo  dofinod  by  sootion  0.1 .6  of  [GMF],  [ 

Relevant  CMIS  agroomonts  defined  in  subclause  6.3.6  aro  repeated  here  for  oomplotonoss.  I 

I 

Table  6:  Agroomonts  On  Paramotor  Usage  Portinont  to  tho  PT  Doloto  SMF  j 

Sorvioo 


SMF  PT-Doloto  Paramotor 

P  i-fc/l 
1 1  W| 

Pcja 

SMF  Agroomonts 

GMIS 
Agroomonts 

Invoke  Identlflor 

M 

6t4 

Linked  Id 

G 

6^ 

Baoe  Object  Claos 

M 

Baoo  Object  Inotanoo 

M 

Scope 

y 

6.2.2.1 

Piltnr 

y 

6.1.2.1 

6.2.2.2 
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SMF  PT-Doloto  Paramotor 

P  r\n 

1  IWI 

SMF  AgroomontG 

GMIS 

Aocoss  Control 

u 

R  /I 
0.c.*+- 

Synchronization 

y 

6.2.2.3 

Managed  Object  Claoo 

G 

6t4.6 

IVIanagod  Object  Inotanoe 

G 

6T2r4- 

Current  Time 

6t2^ 

Erroro 

G 

6.3.6.1,  6.4.4 

6A«  PT  Sot 

This  subclause  providos  agrcoments  portinont  to  the  PT-Sot  SMF  sorvico  dofinod  by  soction  Q.I .8  of  [OMF]. 
Rolovant  CMIS  agroomonts  dofinod  in  subclauso  6.3.3  are  ropoatod  here  for  complotonoss. 

Table  7:  Agroomonts  On  Paramotor  Usage  Portinont  to  the  PT-Sot  SMF  Sorvioo 


SMF  PT-Sot  Paramotor 

P  r\n 

SMF  Agroomonts 

CMIS 
Agroomonts 

Invoke  Identifier 

M 

MM 

&A 

Linked  Id 

G 

&A 

Mode 

M 

6.1.2.2 

Base  Object  Claso 

M 

&AS 

Base  Object  inotanoe 

M 

&^ 

Scope 

y 

6.2.2.1 

mef 

y 

6.1.2.1 

6.2.2.2 

Access  Control 

y 

6tS^ 

Synchronization 

y 

6.2.2.3 

Managed  Object  Class 

G 

&AS 

Managed  Object  Instance 

G 

6v2t4- 
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SMF  PT-Sot  Paramotor 

SMF  Agreomonts 

CMIS 
AgreGments 

Modification  Liot 

M 

6.4.6,  6.3.3.1, 
6.3.3.3,  6.3.3.4 

Attribute  Liot 

y 

6.4.5.  6.3.3.1, 
6.3.3.3 

Current  Time 

y 

&^ 

Erroro 

G 

6.3.3.2,  6.4.4 

 PT  Action 

This  subolauso  provides  agroomonts  portlnont  to  tho  PT  Action  SMF  sorvioo  dof inod  by  sootion  0. 1 .7  of  [OMF] . 
Rolovant  CMIS  agroomonts  dofinod  In  subclauso  6.3.4  aro  ropoated  lioro  for  complotonoss. 

Table  8:  Agroomonts  On  Paramotor  Usage  Portlnont  to  tho  PT  Action  SMF 

Service 


SMF  PT-Action  Paramotor 

ff  1  VVf 

P  g»  f\ 

SMF  Agreements 

Agroomonts 

Invoke  Identifier 

M 

MM 

&A 

Linked  Id 

G 

&A 

Mode 

M 

5.1.2.2 

Base  Object  Claos 

M 

&AS 

Base  Object  Instance 

M 

&^ 

Scope 

y 

6.2.2.1 

Piltnr 

y 

5.1.2.1 

6.2.2.2 

Access  Control 

y 

6t2^ 

Synchronization 

y 

6.2.2.3 

Managed  Object  Class 

G 

&AS 

Managed  Object  Instance 

G 

6t2t4 
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SMF  PT-Action  Paramotor 

p  /■>«•« 

SMF  Agrcomontc 

GMIS 

Agreomontc 

Action  Typo 

M 

C  4  c 

Action  Information 

y 

Current  Time 

y 

Action  Reply 

G 

Erroro 

G 

fe4^ 

6vav40  PT  Got 

ThiG  GubctauGO  providoo  agroomonte  portinont  to  tho  PT  Got  SMF  sorvioe  dofinod  by  Gootion  0. 1 .0  of  [OMF], 
Rolovant  CMIS  agroomonts  dofinod  in  subclauso  6.3.2  aro  ropoatod  horo  for  oomplotonoeg. 

Table  9:  Agroomonts  On  Paramotor  Usage  Portinont  to  tho  PT  Got  SMF  Sorvioe 


SMF  PT-Action  Paramotor 

SMF  Agroomonts 

Agroomonte 

Invoke  Identifier 

M 

MM 

S^ 

Linked  Id 

G 

Baoe  Object  Claco 

M 

fi  4  g 

Base  Object  Inotanoo 

M 

Scope 

y 

s.a.a.i 

1  lllwi 

y 

6.1.2.1 

e.a.a.a 

Aoceoc  Control 

y 

Synchronization 

y 

6.3.2.3 

y 

g  4  c 

Managed -Object  Claoo 

G 

g  4  g  1 

Managed  Object  Inctanco 

G 

Current  Time 

y 

17 


PART  18:  Network  Management 


September  1991  (Stable) 


SMF  PT-Action  Parameter 

P 

Deri 

SMF  Agroomonts 

GMIS 
Agroomonts 

Attributo  Liot 

G 

6.^.6,  6.3.2.1, 
6.3.3.3 

Erroro 

G 

6.3.2.2,  6.4.4 

 prevent 

This  subctauso  providos  agroomonte  portinont  to  the  PT-  Event  SMF  servioo  dofinod  by  soction  9. 1 . 1 0  of  [OMF}. 
Rdovant  CMIS  agroomonts  dofinod  in  subclauso  6.3.1  aro  ropoatod  horo  for  comptotonose. 

Tabic  10: — Agroomonts  On  Parameter  Usage  Portinont  to  the  PT  Event  SMF 
Service 


SMF  PT-Action  Parameter 

n  w| 

Ppn 

SMF  Agroomonts 

GMfS 

Invoko  Idontifior 

M 

Mode 

M 

6.1.2.2 

Managed  Object  Class 

M 

y 

6v4t6 

Managed  Object  Instanoo 

M 

y 

6vSv+ 

Event  Type 

M 

6^ 

Event  Time 

y 

&^ 

Event  Information 

y 

6.3.1.1 

y 

&^ 

Event  Reply 

G 

Errors 

G 

&i3  State  Management  Function  Agreements 
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Gonoral  Agroomonte 


Thoco  agroomontc  addroco  tho  following  SMF  corviooc  dolinod  by  tho  ctato  managomont  ctandard  (STMF]: 

Table  11:  Soopo  of  Agroomonts  Relating  to  SMF  Sorvioos  Dofinod  by  tho  State 

Managomont  Standard  [STMF] 


State  Management  SMF 
Service 


Within  Scope  Of 
Agroomentc 


Related  Managomont 
Support  Objects 


State  Change  Roporting 


Diocrimlnator 


Stato  Chango  Roporting 


Thio  subolauoo  provldos  agroomontG  pertinent  to  tho  Stato  Change  Roporting  SMF  gop/Ioo  dofinod  by  cootion 
0.3  of  [STMF].  Relevant  GMIS  agroemontc  defined  in  oubolauoo  6.3.1  aro  ropoatod  hero  for  oonnpiotoncaG. 

Table  12:  Agroomonts  On  Parameter  Usage  Pertinent  to  tho  Stato  Chango 

Reporting  SMF  Sorvico 


SMF  State  Chango  Report 

tCt\  ijkli  1  wlVI 

P  p  rt 

SMF  Agreemonte 

Agreements  | 

invoke  Idontifior 

M 

Modo 

M 

6.1.2.2 

Managed  Object  Claoo 

M 

y 

A  F\  1 

w.^.  w  II 

Managed  Object  Inctanoo 

M 

y 

&^  1 

Stato  Chango 

M 

y 

6^  1 

Event  Time 

y 

&t2^  j 

State  Change  Information 

— Old  Operational  Stato 

y 

6.3.1.1 

— Now  Operational  Stato 

G 

6.3.1.1 

Old  Uoago  Stato 

y 

6.3.1.1 
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SMF  State  Change  Report 

Parameter 

1  l\r\J 

SMF  Agreements 

CMUSi 

G 

6.3.1.1 

— Now  U&age  State 

— Ola  AomtniGtrativQ  State 

6.3.1.1 

— Now  AomtniGtrattvo  State 

G 

6.3.1.1 

_    _     •  f\.  . 

y 

6.3.1.1 

— Old  Hopair  Status 

G 

 —  

6.3.1.1 

— Now  Ropair  Statue 

— Old  Inctallatien  Statue 

1  ■ 

y 

6.3.1.1 

— Now  Inotallation  Status 

G 

- 

6.3.1.1 

Old  Availability  Status 

y 

- 

6.3.1.1 

— Now  Availability  Status 

G 

- 

6.3.1.1 

Old  Control  Status 

y 

- 

6.3.1.1 

— Now  Control  Statue 

G 

6.3.1.1 

y 

6.3.1.1 

Additional  Stato  Change 
— \pAe 

Current  Time 

y 

672^3 

Evont  Reply 

G 

Errors 

G 

6^4^ 

6t4  Attributes  For  Roprosonting  Relationships  Agroomonts 

&AtA  Gonoral  Agroomonts 

Those  agroonrtonts  addrooo  tho  following  SMF  GOfviooo  dofinod  by  the  AttributoG  For  Roprooonting 
Rolattonohipo  standard  [ARR): 
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Table  13: 


Soopo  of  Agroomonts  Relating  to  SMF  Sorvioos  Dotinod  by  the 
Attributes  For  Roprosonting  Rolatlonshipc  Standard  [ARR] 


Attributoe  For  RoproGonting 
Relationships  SMF  Sorvloo 


Within  Scopo  Of 
Agroomontc 


Rolatod  Management 
Support  Objoctc 


Rolationohip  Change  Roporting 


VfXP_ 

1  %J19 


Event  Fofwarding 
DiGOfiminatof 


6r4.2  Relationship  Change  Reporting 

Thio  oubolauGO  providoo  agroomonto  portinont  to  the  Rolationohip  Change  Roporting  SMF  oorvioo  dofinod  by 
Gootion  Q.3  of  [ARR].  Roiovant  CMIS  agroomontc  doftnod  In  oubolauso  6.3.1  arc  ropcatod  horo  fof 
oomplotonoGS. 


Table  14: — Agroomonts  On  Parameter  Usage  Portinont  to  the  Relationship  Change 
Roporting  SMF  Service 


SMF  Rel  Change  Report 
Parameter 

DA£1 

n 

Agroomonts 

GM4S 
Agroomontc  | 

lnvol<o  Identifier 

M 

M{-} 

Mode 

M 

6.1.2.2 

Managed  Object  Claos 

M 

U 

GAR 

Managed  Objoot  Inotanoo 

M 

y 

Relationohip  Change 

M 

y 

fi  A  p, 

Event  Time 

U 

fi  o  q 

Rolationohip  Change  Information 

Old  UoerObjoot 

U 

6.3.1.1 

— Now  UoerObjoot 

G 

6.3.1.1 

— Old  ProviderObjoot 

U 

6.3.1.1 

— New  ProviderObjoot 

G 

6.3.1.1 

Old  Peer 

y 

6.3.1.1 
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8MF  Rol  Change  Roport 

P  c^rt 

Anrf*f»nnf»ntft 

GMiS 

1  Wl  1  Id  1  lO 

— Now  Poor 

G 

6.3.1.1 

— Old  Primary 

1  1 

y 

6.3.1.1 

G 

- 

6.3.1.1 

— Now  Primary 

Old  Sooondary 

y 

- 

6.3.1.1 

— Now  Sooondary 

G 

6.3.1.1 

— Old  Backup  Objoct  InGtanoo 

y 

6.3.1.1 

— Now  Backup  Objoct  Inotanoo 

G 

6.3.1.1 

Old  BackodUp  Object 
 Inotanoo 

y 

6.3.1.1 

— Now  BackodUp  Objoct 
— Inotanoo 

G 

- 

6.3.1.1 

— Old  Owner 

y 

- 

6.3.1.1 

— Now  Owner 

G 

- 

6.3.1.1 

— Old  Member 

y 

- 

6.3.1.1 

— Now  Member 

G 

6.3.1.1 

— Additional  Relationship 
— Change  Info 

y 

6.3.1.1 

Current  Time 

y 

6^ 

Event  Reply 

G 

Erroro 

G 

6^ 

&S  Alarm  Reporting  Function  Agroomonts 

 General  Agreoments 

ThoGO  agroofDonto  addrooe  tho  following  SMF  oorviooG  defined  by  tho  alarm  reporting  otandard  [ARF): 
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Table  16:  Soopo  of  Agroomonts  Relating  to  SMF  Sorvioos  Dofinod  by  the  Alarm 

Reporting  Standard  [ARF] 


Alarm  Reporting  SMF  Service 

Within  Scope  Of 
Agroomonts 

Related  Management 
Support  Objects 

Alarm  Roporting 

Vrxr. 

1  KJKJ 

Event  Forwarding 
DiGcriminator 
&  Alarm  Rocord 

&St2  Alarm  Reporting 

This  Gubolauso  providoo  agroomonts  portinont  to  tho  Atarm  Roporting  SMF  oorvioo  dofinod  by  soction  0.3  of 
[ARF].  Rolovant  CMIS  agroomonto  dofinod  in  oubolau&o  6.3.1  aro  ropoatod  horo  for  oomplotonooo. 

Table  16: — Agroomonts  On  Parameter  Usage  Portinont  to  tho  Alarm  Roporting 


SMF  Alarm  Roporting 

1  IVU 

SMF  Agreements 

GM4S 
Agreements 

Invoke  Idontifior 

M 

M 

6^ 

Mode 

M 

6.1 .2.2 

Managed  Object  ClaoG 

M 

y 

C  4  C 

Managed  Object  Inctanoo 

M 

y 

Alarm  Type 

M 

R  A  Ft 

Event  Time 

y 

6^ 

Alarm  Information 

— Probable  Cauoo 

M 

6.3.1.1 

Spooifio  Problomo 

y 

— Perceived  Severity 

M 

6.3.1.1 

— Backup  Object  Inotanco 

G 

6.3.1.1 

BaokodUp  Statue 

y 

&^ 
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SMF  Alarm  Reporting 
paramGter 

D 

1  1  WV| 

Rsp 

SMF  Agroomonts 

GMtS 
Agrccmcntc 

— Trond  Indication 

y 

6.3.1.1 

— Throohold  Information 

G 

6.3.1.1 

— Notification  Idontifior 

y 

{3} 

6.3.1.1 

— Correlated  Notifications 

y 

6.3.1.1 

— Generic  State  Change 

G 

6.3.1.1 

— Monitored  Attributes 

y 

6.3.1.1 

M 

roi 

fi    1  1 

D.O.  1  .  1 

— Problem  Text 

y 

6.3.1.1 

— Problem  Data 

y>4 

6.3.1.1 

Current  Time 

y 

Event  Reply 

G 

Errors 

G 

&AA 

[1]  To  avoid  ambiguity,  tho  DIstingulshod  Namo  form  of  this  paramotor  shall  bo  Impiomontod  and 
may  bo  used.  Uso  of  Local  Distinguishod  Namo  and  Non-Spooifio  forms  arc  beyond  the  scope 
of  those  agroomonts.  If  an  implomontation  is  unable  to  docodo  or  understand  tho  semantics  of 
this  paramotor,  an  appropriate  CMIS  orror  (i.o.,  Invalid  Attribute  Valuo)  shall  bo  roturnod. 


[2]  To  limit  implomontation  complexity,  tho  maximum  numbor  of  SET  itoms  oontainod  within 
the  Spocific  Problems,  Corrolatod  Notifications,  and  Propoood  Repair  Action  paramotors 
vyhich  rocipionts  must  bo  able  to  process  shall  bo  6^1  . 

[3]  To  limit  implomontation  complexity,  tho  maximum  longth  of  tho  Notification  Id  parameter 
shall  bo  32  bits. 

[4]  To  limit  implomontation  comploxity,  tho  maximum  longth  of  tho  Problem  Text  parameter 
which  rocipionts  must  be  able  to  process  shall  bo  266  octets. 

[6]  Use  of  the  Problem  Data  parameter  is  beyond  tho  scopo  of  those  agroomonts. 
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^  Event  Report  Management  Funotion  Agreements 


&rSrA  Gonoral  Agroomonto 

Thooo  agroomontc  addrooo  tho  following  SMF  oop/iooc  dofinod  by  tho  ovont  report  managomont  ptandard 


Table  17: — Scope  of  Agreements  Relating  to  SMF  Servioos 
Report  Management  Standard  [ERMF] 


Evont  Report  Managomont 

Rolatod  Managomont 
Support  Objoctc 

Within  Scope  Of 

Initiation  of  ERF 

Vac 

Evont  Forwarding 
DiGoriminator 

Tormination  of  ERF 

Vr>r 

I  WW 

Evont  Forwarding 
Dioorinninator 

EFD  Modification,  Suoponoion, 

Ynr 

Rocumption 

Evont  FoPAfarding 
Diocriminator 

 Initiotion  Of  Event  Report  Forwarding 

This  6utx)tauG0  provldoc  agroomonts  portinont  to  tho  Initiation  of  Evont  Report  Forwarding  SMF  sorvioo  dofinod 
by  sootion  0.2  of  [ERMF],  Rolovant  CMIS  agreements  defined  in  subciauco  6.3.6  are  ropoatod  horo  for 
complotonoee. 


Table  18: — Agreements  On  Parameter  Usage  Pertinent  to  tho  Initiation  of  Event 
Report  Forwarding  SMF  Service 


SMF  Initiation  of  ERF 
Parameter 

SMF  Agreements 

GM4S 
Agreements 

lnvol<o  Idontifior 

M 

fJll-\ 

Managed  Objoot  Claoo 

M 

G 

4  g 

wT"TTTy 

Managod  Objoct  Inotanoo 

y 

G 

6.2.1,  6.3.6.1 
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SMF  Initiation  of  ERF 
Parameter 

P 

1 

8MF  Agroomonts 

CMIS 
AgroomontG 

Support  Objoot  Inctanoo 

y 

- 

AoGOGG  Control 

y 

- 

Roforonoo  Object  Inctanoo 

y 

- 

Dicoriminator  Conotruot 

y 

G 

6.1.2.1 

6.4.6,  6.3.6.2 

Declination  Addrccc 

y 

G 

6.4.6,  6.3.5.2 

Backup  AddroGO 

y 

G 

6.4.6,  6.3.6.2 

Active  Addrccc 

y 

G 

-  

6.4.6.  6.3.6.2 

Administrative  State 

y 

G 



6.4.6,  6.3.6.2 

Operational  State 

G 

6.4.6,  6.3.6.2 

Uoage  State 

_ 

G 

6.4.6,  6.3.6.2 

Availability  Statue 

- 

G 

6.4.6,  6.3.6.2 

Allomorphio  List 

y 

G 

6.4.6.  6.3.6.2 

Packageo 

y 

G 

6.4.6,  6.3.6.2 

\AJor\W  MTPk 

Li 

6  4  6  6  3  6  2 

6  4  6 

6^3:^ 

Start  Time 

y 

G 

6.4.6.  6.3.5.2 

Of^rx  TifTiA 

y 

G 

6.4.6.  6.3.6.2 

Schodular  Name 

y^ 

G^ 

{4} 

6.3.6.2 

C^A  irront  Tirnn 

y 

6t2^ 

Erroro 

G 

6.4.4.  6.3.5.2 

[1]  As  spocifiod  In  [CMIP],  tho  valuo  'AblD  {)'  gIuII  bo  ucod  to  roprooont  an  all  pace  DlGcriminatof 
Con&truGt.  If  thiG  paramotor  is  omitted  from  tho  roquost.  tho  all  pasc  value  ehaH  bo  assigned  to 
tho  Diooriminator  Construct  attribute 
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[2]  Tho  Daily  Sohoduling  Packago.  if  cupportod  by  an  objoct.  chall  cupport  at  minimum  tho  default 
24  hour  Intofval. 

[S]  Tho  Wookly  Sohoduling  Packago,  if  cupportod  by  an  objoot.  chall  cupport  tho  dofauit  valuoc  for 
Start  TImo  and  Stop  Timo  attributoo.  Tho  Wook  Mack  anributo  chall  cupport  sohoduling  for  oach 
day  of  tho  wook,  and,  at  a  minimum,  the  dofauit  2A  hour  porlod  for  Intorvato  of  tho  day. 

[4]  Support  for  the  Extornal  Sohodular  Packago  ic  boyood  tho  ecopo  of  thoco  agroomontc. 


St^^  Termination  Of  Event  Roport  Forwarding 

This  subdauso  providos  agroomontc  pertinent  to  the  Termination  of  Event  Report  Forwarding  SMF  corvico 
defined  by  soction  Q.3  of  (ERMF).  Rolovant  CMIS  agroomontc  defined  in  cubclauso  6.3.6  aro  repeated  horo  for 
complotonoss. 


Table  19:  Agroomonts  On  Parameter  Usage  Pertinent  to  tho  Termination  of  Event 

Roport  Forwarding  SMF  Service 


SMF  Termination  of  ERF 
Parameter 

Dan 

SMF  Agreements 

GMIS 
AgroomontG 

Invoko  Idontifior 

M 

6:4 

Linkod  Id 

G 

&4 

Baso  Objoct  Claos 

M 

g  4  c 

Baso  Objoot  Inotanoo 

M 

Soopo 

y 

6.2.2.1 

y 

6.1.2.1 

Aooooo  Control 

y 

&2t4 

Synchronization 

y 

6.2.2.3 

G 

(i  A  R 

Managed  Objoct  Inotanoo 

G 

6:2r4 

Current  Timo 

y 

fi  o  o 

Erroro 

G 

6.3.6.1,  6.4.4 
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 EFD  Modifioattont  Sueponsion,  and  Resumption 

This  suboiausQ  providoG  agroomonto  portinont  to  tho  Evont  Forwarding  Discriminator  Modificatton.  Sueponsion. 
and  RoGumption  SMF  sorvtoo  defined  by  sootion  0.4  of  [ERMF].  Rolovant  CMIS  agroomonts  dofinod  in 
subolauGO  6.3.3  arc  repeated  here  for  Gomplotonoss. 


Table  20: — Agroomonts  On  Parameter  Usage  Portinont  to  tho  Evont  Forwarding 
Discriminator  Modification,  Suspension,  and  Resumption  SMF  Sorvico 


one  CCf% 
oivi  I  cr  tiF 

Mod/SuGpond/Rocumo 
Pa  remoter 

Flop 

oMr  AgroomoniG 

M 

MM 

6.4 

Linkod  Id 

6 

Modo 

M 

6.1.2.2 

Baso  Objoot  Claoo 

M 

- 

GAR 

M 

6  2  1 

Scope 

y 

- 

6.2.2.1 

Filtfir 

y 

6.1.2.1 

6.2.2.2 

AoGOGS  Control 

y 

6^ 

Synohronization 

y 

6.2.2.3 

Managed  Objoot  ClaGc 

G 

c  4  g 

Managod  Objoot  Inotanoo 

G 

6.2r4- 

DlGorinrtinator  Conotruot 

y 

G 

6.1.2.1 

6^^ 

6.3.3.1.  6.3.8.3, 
6.3.3.4 

Dootlnation  Addrooo 

y 

G 

6^4:€r 

6.3.3.1,  6.3.3.3, 
6.3.3.4 

Backup  AddrooG 

y 

G 

6.3.3.4' 
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gMf-EFD 
Mod/Sucpond/RoGumo 
Paramotor 

P/Nfl 

SMF  Agroomonto 

emus 
Agroomonto 

Aotivo  AddroGS 

y 

G 

6.3.3.I.  6.3.3.3, 
6.3.3.4 

Adminictrativo  Stato 

y 

G 

6^4.Sr 

6.3.3.1.  6.3.3.3, 
6.3.3.4 

Allomorphio  List 

y 

G 

6^^v&r 

6.3.3.1,  6.3.3.3. 
6.3.3.4 

Wook  Maok 

y 

G 

6^4^ 

6.3.3.1,  6.3.3.3, 
6.3.3.4 

Intorvalc  Of  Day 

y 

G 

6.4.6, 
6.3.3.1. 
6.3.3.3. 
6.3.3.4 

Start  Timo 

y 

G 

6.4.6. 

6.3.3.1.  6.3.3.3, 
6.3.3.4 

y 

G 

6^4^ 

Stop  Timo 

6.3.3.1,  6.3.3.3, 
6  3  3  4 

Schodular  Namo 

y>4 

G>4 

6^ 

6.3.3.1, 
6.3.3.3, 
6.3.3.4 

Current  Timo 

y 

Erroro 

G 

6.3.3.3,  6.4.4 

[1]  Ac  opooifiod  In  [CMIP],  tho  valuo  'AND  ()'  chall  bo  ucod  to  roprooont  an  all  pace  Discriminate 

Ck)n6truot. 
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[2]  Tho  Daily  Sohcxjuling  Pao^ogo,  if  supportod  by  an  objoot.  shall  support  at  minimum  tho  default 
24  hour  intofval. 

[3]  Tho  Weekly  Scheduling  Packago.  if  supportod  by  an  objoot,  shall  support  tho  default  values  for 
Start  Tirrv)  and  Stop  Time  attributes.  Tho  Week  Mask  attribute  shall  support  scheduling  for  each 
day  of  tho  wook,  and,  at  a  minimum,  the  default  24  hour  period  for  intervals  of  tho  day. 

[4]  Support  for  the  External  Schodular  Package  is  beyofxi  the  scope  of  those  agreements. 


5      Management  Functions  and  Services 


5,1      General  Agreements 


5.1.1         Cbnv^ions  Used  tn  SMF  Agreements 

£ac^  Sy^m  Management  Function  defines  a  set  of  services  referred  to  In  thfe  document  m  *$MF  services*; 
Agreements  pertinent  to  SMF  services  are  provided  in  the  fc^ovtt'ing  subclauses.  Each  subdause  contains  a 
series  of  t^;^  as  fdlovi/s, 

For  each  service,  a  normative  table  references  text  agre^ner^  which  constrain  ^  U6a$e  and/or  value 
of  the  associated  service  parameters.  Text  agreements  defined  elsewtiere  In  tWs  docLH7i«t  are  referenced  by 
Ifause  nurrriaef.  The  lack  Of  a  row  or  reference  signifies  no  agreement  beyorxl  tt\&  base  standard. 

tSfc^ eS  p(3iiJe  pararneter  usage  tor  recpjest;  Indfcatiw^  respor^  atxl  confirmation 

iervice  primitives.  TlT«se  codes,  defined  in  subclause  t.8.3  di  these  agreemerte  ^Classification  of 
ponfonnance),  tl  ISO/IEC  TR 10000- 1  (Framework  and  Taxonomy  of  I  SFs)  {ISPFRMJ,  and  in  ISO/IEC  TR  8509 
(Service  Conyentjons)  [ISPSRVC],  are  repeated  here  for  read^  convenience: 
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M  Mandatory 

0  Optionai 

C(p)    If  Condition  p  exists,  then  parameter  .j$'lT?andatOr^  otherwise,  the 

p^tfametef  Is  not  applicable. 
X  Excluded 

1  Out  Of  Sco  pe 

In  these  agreements,  this  means  that,  tor  thfe  correspondkig  element, 

*  Implementations  may  use  It  outside  Ihe  scc^e  of  these  agreements. 

*  conformance  tests  shall  not  be  provided  for  It, 

*  Implementations  may  conform  to  other  agreenieriilWi  f  W  rk?uired, 
f  no  requirements  are  placed  on  either  transrrwtter  or  receiver  to  support 

i 

*  receiver  actions  are  unspecified  when  present. 

Not  Applicable  ^ 

The  value  of  the  parameter  Is  identical  to  the  corresponding  parameter  lil 

the  Interaction  desaibed  by  the  preceding  related  service  primitive. 
U       The  use  of  the  parameter  Is  a  service-user  option. 
P       The  parameter  is  mapped  directly  onto  the  corresponding  parameters  of 

the  CMIS  service  primitive;  refer  to  subclause  Q  for  agreements  regarding 

this  pass-through  para^ 


tri IddMlon,  flie'  cohv^ntloh  •A>  B"  Is  iised  In  horrhatlve  tat^ es  tb  Indicate  both  the iisap^p^c^le^  by  the  fcese 
standard  (A)  and  the  addittonaJ  constraint  imposed  by  these  agreements  (B).  This  convention  Is  Intended  to 
call  attention  to  agreements  which  modify  the  usage  of  a  service  param^er. 

Unless  otherwise  rKrted,  cc^vJitlonat  parameters  (C)  sh^  be  present  according  to  the  corKOtJons  defxied  in 
fCMlS]  arKt  the  referenced  System  Management  Function  base  standard. 


Genera)  A9reements  Referenced  By  Many  SMf  Servieet 

The  fdlowing  general  agreements  pertain  to  some  or  all  of  the  System  Managenwnt  FurKtloh  services  defined 
thrcxighoiA  cteuse  5.  Normative  tables  for  each  SMF  service  reference  these  general  ayeements  where 
applicable.  These  agre^inents  do  not  apply  to  SMF  services  and  parameters  which  do  not  reference  thern. 


5.1.2. 1  Maximum  Length  of  Notification  Identifier 


To  firrat  lrTQ>lem«itation  comf^extty.  the  maximum  length  of  the  Notification  IdentTjef  parameter  shall  be  32  bits. 
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5.1^2         Maximom  Number  of  SET  Items 

To  Bmft  ln^3iemwttatlon  conr^irfexfty,  the  tnaixlmiim  itu 
parameters  lhat  recif^ents  must  be  aWe  to  process  shall  be  64^ 


5.1^3         Maximum  Length  of  AddHional  Text 

To  IJmlt  lmpiemer»!atfon  cc«Tfi|rfe>(fty;  the  ma>^mum  teng^  <3i  fiie  AckStlonjJ  Te^d  pamm«ief  wWch  recipients 
must  be  able  to  process  ^t^I  be  256  octets. 


5.1^4         U«eof  Acfditional  Info 

Editor**  Note:  [The  Additional  Information  paramet^^  de^ 

•signScance  Indicator/  H  requires  tl-«t  "[e]ven  If  the  AddSion^  Information  p^ameter  is  nd 
fijly  iflTderstood,  an  event  report  indication  shaS  be  Issued  to  the  US^.  Indication  that  the 
Adcfitional  Information  parameter  Is  n<«  fully  undwstood  te  a  tpcatf  matter."J 


Object  Management  Function  Agreements 


S^f         Generai  Agreements 

These  agreements  re<¥uiffi  support  for  the  SMF  services  defined  by  the  obfec^frsnagerrient  ^ndard  [OMF]. 

These  a0*eement8  also  require  conformance  to  the  abstract  syntaxes  identified  In  dsme  11  of  the  objeca 
management  standard  |OMF]  arxl  specified  in  (Df^l) ,  with  the  exception  of  event  record  subdasses.  If  support 
for  the  log  contrd  standard  [LCF]  as  described  In  clause  S.7  Is  clainwd,  then  ait  {OMF]  event  record 
subclasses  shall  also  be  recjulred  by  these  agreements.  These  agrewieftfs  permit  optioned  n^jo^^on  of  the 
system  nrtanagemerU  fL9lC  specified  in  dause  lO  pf  |OMf]>, 


S^Z         Objea  Creation  Reporting 

This  subclause  provides  agreements  pertinent  to  the  Object  Creation  Reporting  SfvlFseivlce  defined  by  section 
9.2  of  [OMF] .  Sutxilause  6provldes  agreements  pertinent  to  CMIS  services  and  pass-through  parameters  used 
by  this  SMF  sendee, 

Table  1:      Agreements  On  Parameter  Usage  Pertinent  to  tiie  Object  Creation 
Reporting  S  MP  Service 
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^eportl)i9  Parameter 

Dam 

rieci 

Rsp 

SMF 
Agre^mehtl 

EvontType 

Event  Information 

Source  Indicator 

Attnbute  List 

y 

;  Notification  fdenfifer 

1 

5:1 

Correlated  NotHicatJons 

U 

5.1.2.2 

Additional  Texl 

U 

5.1.2.3 

;  Additional  Info 

u 

5.1.2.2,5:1.2^ 

5.2.3         Object  Deletion  Reporting 

This  sufaclauseproNdctesa£^eements  pertlnHsnt  to  tH6  Direct  D^eWll^pltJh^ 

9.3  of  lOMFJ.  $ut>clause  6 provides  agreements  pertinent  to  C^IS  services  and  pa$s-ilvough  parameters  used 
by  this  SMF  sen^^ 

Table  2:      Agreements  On  Parameter  Usage  Pertinent  to  the  Object  Deletion 
Reporting  SMF  Service 


SMF  Object  DeleUon 
Reporting  Parameter 

Req 

Rsp 

SMF 
Agreemehtl 

Event  Type 

m 

C{=) 

Event  fnforn^ticm 

Source  Indicator 

u 

• 

Attnbute  list 

• 

Notification  tdenfifier 

§ 

5.1.2.1 

Co^  Notifioatidns 

i 

* 

5.1.2.2 

;  Additional  Text 

i 

5.1.2.3 

Additional  Info 

i 

5.1.2.2, 5.1.2.4 
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S.2.4         AttrliHtteValuft  Change  Reporting 

This  subdausB  provides  agreements  pertinent  to  the  Attritxite  Vafu«  Change  Reporting  SMF  sefvice  d^ed 
by  section  9.4  of  (OMFJ.  Subclause  6  provides  agreemerta  pertin^  to  QM^  $ei\4c6S  and  pass-through 
parameters  used  by  this  SMF  service; 

Table  3;     Agreements  On  Parameter  Usage  Pertinent  io  the  Attribute  Value 
Change  Reporting  SMF  Service 


SMF  Attr  Value  Change 
Report  Parameter 

Req 

SMF 

Event  Typo 

m 

Event  tnformaticHi 

Source  Indicator 

Attribute  Identtfier  List 

i 

AttritHite  CHange  Definition 

Attribute  Identifier 

M 

Old  Attribute  Value 

0 

New  Attribute  Value 

M 

i 

NotifioatiCHi  tdentifter 

i 

5:1  2.1 

Correlated  NotMoations 

i 

5.1.2.2 

Adcfitional  Text 

11 

5.1.24 

Additional  Info 

i 

$,tJ2.2;5.t.2^ 

5.2.5  PT-Creale 

Ttag  8Ut>clau$e  provide?  no  additional  agreements  pertinent  to  Ihe  Ft-Oaate  SMF  advice  beyond  the  base 
standard  definitlm  k\  section  9.5  of  [OMF],  Subclause  6  provides  agreements  pertlnemtcCfcftIS: services  and 
pass-through  pamm^^  used  by  this  SMF  sen/ice^ 
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This  subcJause  profvtdes  no  addltioral  agreements  pertinent  lo  the  PT-Detete  SMF  eorvfce  beyond  the  base 
starKJarcl  definitfaKi  in  section  9.6  of  [OMFJ,  Subclause  6  provides  agreemetspertinem  to  CWIS  services  and 
pa$$-thf ouoh  parameters  i«ed  by  this  SMF  services 


S^T  PT-Sel 

This  subdatse  provides  no  additional  agreements  pertinent  to  the  PT-Set  SMF  service  beyond  the  base 
standard  d^lnltton  in  section  9.9  of  (OMFJ.  Subclause  6  provides  agreements  perttner^  to  CMIS  services  and 
pass-through  pararneters  used  by  this  SMF  service. 


This  subclause  pro^Aies  no  addittonal  aQreernerits  pert^^  beyond  the  t»ase 

standard  definition  Resection  9. 7  of  [OMF].  Sulxlause  6  provides  agreements  pfrti^  services  and 

pass-thnxigh  par»t«t^s  used  by  tW$  SMf^  sei^^ 


TWs  siixteuse  provides  no  additional  agreements  pertinent  to  the  Pt-6^ 

Standard  deflnttkxi  In  section  9.9  of  (OMF] .  Subclause  6  provides  agreements |>ert^^  and 
pass-through  paramet©^  used  by  this  SMF  service. 


5.2.10  PTCveni 

TWs  sutx^ause  piwtdes  no  additional  agreements  pertiner*  to  the  PT-Evem  SMF  s«vtce  beyond  the  base 
standard  defirttionin  sec«ion9. 1 0  of  {OMF]<  Subclause  6  provides  agreements  pertinent  to  CI^S  services  and 
pass-through  pa«met^  used  by  this  SMF  sen^ce^ 


5.3      State  Management  Function  Agreements 


5.3.1        Genml  Agreements 

Thes6  agr6em«i8  rec;^^  support  for  the  SM  F  servfces  d^med  by  tf»  state  mane^3iem«Tt  ^tendeud  IST^ijJIf]^ 

The$0  agre^tl&rts  also  require  conformance  to  the  abstract  syntaxes  identified  m  clause  tl  of  the  state 
management  st^ard  [STMF]  and  specified  in  [DM!  j.  with  the  exception  d  evera  record  siAcJass.  If  support 
for  the  log  cor^  standard  LI-CFJ  as  described  in  clause  5.7  Is  claimed,  then  a8  ISTMFJ  event  record 
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$Mi;>o^$$i$$  $h$ii{at$o  b^f0C|uM  by  ^$$0  a0r$$»i$nt$.  Th0$»agr«iem$nt$  permit  opttonal  ne9oti$tioii  of  tfi$ 
State  Change  Reporting  functiwE^  unit  specified  \n  clause  10  of  [STMFI> 


5,3.a        State  Change  Reporting 

Tl^^i^i^ose  provides  agreements  p^rttnentiothe  SEa|0CH$t)00{^$pQt!tng$MF$^iced^ed  by  se&tton 
d<l  of  [SIMFJ.  Subclause  6  iHOvides  agre^er^s  pervert  to  OMS  seiwes  and  ji^ss-ltirough  paratneters 


Tabie4: 

Reporting 


BiAf  State  Change  Report 
Parameter 

ill 

m 

SMF 
Agreements 

Event  Type 

i 

i 

£vem  Information 

Source  Indicator 

i 

Attribute  Identifier  Ust 

i 

Slate  Change  Definition 

Attribute  Iden^ler 

i 

Old  State  Attribute  Value 

i 

u 

V  State  Attribute 

Value 

Notifiqation  Mentlfier 

u 

5.1.2.1 

Correlated  Notification^ 

u 

6.1.2.2 

Additional  Text 

u 

Additional  Info 

u 

M 

5*1.2,2, 5.1.2.4 

5.4      Attributes  For  Representing  Relationships  Agreements 
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Oeneral  Agr^^m^rils 

Th^0  agr$0m0ni$  require  support  for  tho  $MF  servloee  defined  by  the  mM^imm^^t^r^ 
Retatibnshlps  standsBtl  [ARRJ* 

These  agreenienlsarso  require  conformance  to  the  abstract  syntaxes  identrfled  in  clause  1  '1  of  th'e  attributes 
lor  repfe$ent^f«|  relat^oni^p$  ^tarjdard  |ARRj  and  specified  in  [DMl),  with  the  exception  of  event  record 
subcTass.  If  support  for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [ARB] 
event  recorcJ  ^uljotasse^  $halt  also  be  required  by  these  agreements.  These  agreements  pemnit  optional 
Regotiatjon  of  Ihe  Relaiionshrp  Change  Reporting  functional  unit  specified  in  clause  1 0  of  ( ARRp 


$A2        Belationshtp  Change  Reporting 

This  subclause  pr£Witre$  agreemerjts  pertinent  to  the  Relationship  Change  Reporting  SMF  sen/Ice  defined  by 
section  9, 1.1  of  [ARB],  Subdause  6  provides  agreements  pertinent  to  CMIS  services  and  pass-through 
pararnetefs::use«li.^iM  SMF  services 

Table  5:      Agreements  On  Parameter  Usage  Pertinent  to  the  Relationship  Change 
Reporting  SWtF  Service 


$MF  Ret  Chajige  Report 
Parameter 

ill 

SMF 

Agreements 

Event  Type 

i 

Event  Informatlan 

Source  Indtcalof 

i 

Attribute  identifier  list 

i 

R^aHons^p  Change 
Infomjation 

Attribute  Identifier 

m 

M 

Old  Rel  Attribute  Value 

i 

M 

New  Rel  Attribute  Value 

m 

% 

Kotifloatlpn  Identifier 

i 

5.1.2, 

1 

Correlated  Notlficatioh$ 

i 

5.1. Z2 

Additional  Text 

i 

5.1.2.: 

3 

Addi^onal  Info 

i 

5.1.2.2,  5.1.2.4 
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BM      Alarm  Reporting  Function  Agreements 


These  agr^emehts  r^quN  support  for  the  SMF  setvlc^s  ctefjtwd  by  U^^^larm  reportlnfii  standard  (AftFJ. 


These  aQreemenls 

also  mqutre  conformance  tO  the  ebstraf*  Syntaxes  Identified  in  clause  1 1  of  the  alarm 

ffipordrtgi  ^nctard 

[ARF|  and  specified  in  [OMl],  with 

i^e  exceptkxn  of  m&ti  rBoosd  subclass*  if  support  for 

the  log  control  standard  [LCF]  as  described  in  claifse 

5.7  is  claimed,  then  all  [ARFJ 

event  reOor> 

isubciasses 

8h£dl  also  be  requlrs^  by  these  agreements. 

These 

agreements  p^mit  optional  i 

negotia^n    the  PMm 

Msam  Reportli^ 

This  sulx^ause  puttvides  agreements  pertinent  to  the  Aiamn  Rspcxting  SMF  sen^edeSned  by  section  d<d  of 
|AfiF),  Subclause  6  provides  agreements  pertinent  to  ClwiS  servioes  and  pass-through  parametere  used  by 
thisiiSMiisetvice. 

Table  6:     Agreements  On  Parameter  Usage  Pertinent  to  the  Alarm  Reporting 

$Mii:Ser»lce 


SMF  Alarm  Reporting 
Parameter 

Req 

Rsp 

SMF 

Agreemeht$ 

Event  Type 

1 

iill 

Event  Information 

Probable  Cause 

m 

Specific  Problenns 

i 

♦ 

5.1.2.2 

Perceived  Severity 

m 

Backup  Object  Instance 

i 

III 

Backed  Up  Status 

i 

* 

Trend  Indication 

i 

Tteshold  Informatioi^ 

i 

t^otifloation  Identifier 

i 

5  J  .2*1 
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SMFAfarm  Reporting 

Req 

III 

SMF 

f^aratnetdr 

ISiriiiiniitiiti 

n 

Sta.te  Chahae  DefiniSon 

til 

OldSt^te  AttrV^iue 

i 

Nqw  St^tQ  Attr  V^ue 

i 

MonHoredl  Attributes 

i 

Proposed  Repsir  Aqtfon 

u 

5.1.2.2 

A(jlctitiOn^  Text 

u 

5.1.2.3 

A<tCtitiOnal  info 

u 

5.1.2.2,  5.1.2.4 

|t]  To  avoid  jtmblgufty,  the  Dl^nguished  Name  form  of  this  parameter  shalt  be  Implemented  atxJ 
may  be  us©!  Use  of  Local  Distinguished  Name  and  Non-Specific  forms  are  beyond  the  scope 
<tf  the$$i  agreements,  if  an  implementation  Is  unable  to  decode  or  understand  the  semantics  Of 
8ns  parameter,  an  appropriate  CMIS  error  (j<e<*  Invalid  Attribute  Value)  shall  be  returned. 


5,6       Event  Report  Management  Function  Agreements 


$.d.1         General  AQreemenls 

These  agreements  require  support  for  the  SMF  services  defined  by  the  event  report  management  standard 

These  agreemen|$  also  require  confomiarice  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  event  report 
management  statvfard  [ERMF]  and  specified  In  [DMI].  These  agreements  permit  optional  negotiation  of  the 
WOnltor  Everjf  Report  Management  and  Svent  Report  Management  functioral  units  specified  in  clause  10  of 
piMili 


5.6.a        Initiaiion  Of  Bvent  Report  Forwarding 

Tf^S  subclause  provides  agreements  pertinent  to  the  initiation  of  Event  fieport  Fon^van^lng  SMF  sen/toe  defined 
fay  section  9.2  of  [ERMF|.  Subclause  6  provides  agreements  pertinent  to  CMIS  services  and  pass-through 
parameters  used  by  this  SMF  service. 
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Table  7:      Agreements  On  Parameter  Usage  Pertinent  to  the  Initiation  of  Event 
Bepori  rorwardfng  SIVII=  Service 


SMF  InttiattOfiof 

ill 

mm 

Parameter 

Agreements 

Discriminator  Construct 

i 

i 

9.  i  u£*  f 

ft 

M 

m 

s ACuve  ussiinauon 

m 

MWt  uri  loll  a.uVQ  QtaiQ 

'(^ 

M 

vJpcfciLIUi  lal  Oldlp 

m 

AHrimr>f  nh<s 

M 

r'innfi-rmAH  JUtr\H*a 

weeKiy  ocnociuitny  noCKay^ 

Week  Mask 

i 

i 

PI 

Daily  Schoduling  Package 

Intervals  Of  Daj^ 

i 

i 

m 

DuraiKon  PadkagI 

Start  Time 

i 

i 

m 

StbpTffne 

i 

i 

m 

Bctemai  Soh0(tular  Paoka0$ 

Sch^dulariName 

i 

ill 

m 
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ft|  As  specltlecf  in  (CMIPJ,  ih^  valu^  "AND  {}*  shaB  be  used  to  mpmmwmw^fwmmfmt 
CkMisferuct,  ff     param^r  is  omitted  from  the  request,  tfie  all-pass  value  shall  be  assigned  to 
Dlscrlffilitaior  Con$truot  ^ttrlbutd. 

|2|  The  Dally  $<sh«dUtlng  Psickage,  If  supported  by  an  object.  $ha«  support  at  minimum  the  default 

|3|  Ifm  Weeldy  ^cbedullng  Pacioge,    suppcated  by  an  object,  shall  support  the  Week  Mask 
mtmm  for  egoh  <ray  of  tKe  week,  and,  at  a  *nlnlmqm,  the  default  24  hour  period4qrJrttefvai$ 

|41  The  Duration  Package.  ^  supported  hy  ar»  obfect.  shall  sipportthe  defauft  v^uWWWrrife 
atidi$topiiiltne;a!!ributes^  " 

|5|  SiQi^Kat  fbf  ihe  External  Scheduler  Package  is  beyond  the  scope  of  these  agreemetit$. 


5.^9         Termination  Of  Event  Report  Forwarding 

This  subclause  provides  no  additional  agreements  pertinent  to  the  Termination  of  Event  Report  Forwarding 
l^F  service  beyond  theiwse  standard  definition  In  section  9^3  of  [ERMF] .  Subclause  6  provides  agreements 
pertfin®TltoCMIS  services  and  pass-through  parameters  used  by  this  SMF  service. 


$.6.4        EFD  Modlfteation,  Suspension*  artd  Desumpttoi) 

Tfi^sei^lauseprovldesagreements  pertinent  loihe  Event  Fonwarding  Discriminator  Modlficatton,  s 

mvi  Re$urrp:lon  Sf4F  service  defined  by  section  9.4  of  {ERMF|*  Subclause  6  provides  agreements  pertinent 

toCMtS  services  and  pass-thtough  parameters  used  by  this  Wi¥  setvice. 

Table  S:      Agreements  On  Parameter  Usage  Pertinent  to  the  Event  Forwarding 
Discriminator  !\flodIficatlon»  Suspension,  and  Resumption  SMF  Service 


srytF  £FD 

Mod/Suspend/Besume 
Parameter 

ill 

wm 

Agreements 

Disdnmln^or  Construct 

i 

i 

Destinalkm 

i 

i 

Backup  Dest  Ust  Package 

Backup  Destinaltori  U$t 

i 

i 
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Mocl/SMSperxi/Resume 

ill 

iii 

Acttve  u^&tinauon 

m 

Adnilnlstraliv©  State 

M 

m 

m 

iMocfe  Package 

Confirmed  Mode 

it-it 

y 

'■ir>k 

m 

Weekly  Scheduling  Package 

— - — ■  

Week  Mask 

i 

m 

M 

Daily  Scheduling  Package 

s::::s|f!lt<*fttfll<S  Of  Hav 

•::::::W:l!HW;-¥«Hi«>  WCljF: 

Duration  Package 

Start  Time 

i 

1 

11 

Stop  Time 

i 

i 

1]: 

External  Schedular  Package 

Schedufar  Name 

U>! 

C>l 

[51 

m  As  specified  in  [CMIPJ,  the  valUB  "AND  {)"  shall  be  used  to  represent  an  i^l-pass  Discriminator 

|2|  The  Dally  Scheduling  Package.  If  supported  by  an  ob|ect.  shail  support  at  minimum  the  default 
Z4  houf  ^erval> 

|3|  The  Weefdy  Scheduling  Package,  if  supported  by  an  object^  shad  support  the  Week  Masic 
attrMe  lor  each  day  of  the  week,  and,  at  a  minimum,  the  default  24  hour  period  for  Intervafs 
c^the  day: 

f4|  The  Duifatfon  Package,  ^  supported  by  an  object,  shall  support  the  default  values  for  Start  Time 

anid:$t£;pi:^imei:a£^ 

|$|  ^i^i^DCit  iot  Sie  Exti^r^l  Schedular  Package  is  beyond  the  scope  of  thi^  agrei^ents. 
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5.7       Log  Control  Function  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

Security  Alarm  Reporting  function  Agreements 
^efer  lathe  Working  Implementation  Agreements  Document.) 

$S      Secartly  Audn  Trail  Function  Agreements 

(pefer  to  the  W<:ffkinp  Imjirfementatlon  Agreements  Document.) 

5.10  Objects  and  Attributes  tor  Access  Control  Agreements 
(Refer  tothe  Wmking  Imi^em^atlon  Agreements  Document) 

5,1^      Accounting  Meter  Function  Agreements 

(Refer  lothe  Wwklhg  Imi^ementation  Agreements  Document.) 

5.ia     Workload  Monitoring  Function  Agreements 

^efer  to  the  WofklriQ  Imptement^tion  Agreements  Document.) 

5.13  Smnmarl2atlon  Function  Agreements 
$^efef  to  the  Working  Implementation  Agreements  Documerrt:<) 

5.14  Test  Management  Function  Agreements 

^efer  lotheWctfkIng  ImpJementatlon  Agreements  Document) 

5.1 1  :;onfidence  and  Diagnostic  Test  Classes  Agreements 
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(R0Jertothe  Work&iQ  Impfemetitatioft  Agreeflient©  Document) 
6      Management  Communications 

This  clause  identifies,  in  detail,  use  of  the  management  communications  services  and  protocols,  based  on  the 
standards  defined  in  [CMIS],  [CMIP],  [ADDRMVS/P]  and  [CANGETS/P]. 

This  clause  covers  the  agreements  pertaining  to  the  use  of  associations  over  which  to  carry  management 
PDUs,  agreements  pertaining  to  the  services  offered  to  a  CMIS  Service  User  (in  terms  of  the  functions  defined 
in  clause  5),  agreements  pertaining  to  the  protocol  used  to  convey  the  management  PDUs,  and  agreements 
pertaining  to  the  services  required  of  other  layers  in  order  to  convey  the  management  PDUs  defined. 

6.1  Association  Policies 

Associations  are  established  using  the  procedures  described  in  [ACSEP]. 

6.1.1  Application  Context  Negotiation 

These  lAs  specify  the  negotiation  of  application  contoxto  as  dosoribodthe  Systems  management  application 
context  specified  in  [SMC].  Other  application  contexts  are  outside  the  scope  of  these  agreements. 

6.1.2  Functional  Unit  Negotiation 

These  lAs  specify  that  System  Management  Functional  Units  are  negotiated  as  specified  in  [SMO]. 

6.1.3  Security  Aspects  of  Associations 

(Rofor  to  the  Working  Implomontation  Agroomonts  Documont.) 

the  ACSE  airthentfeatiort  wecharilsnns  end  associeted  dele  types  ehall  be  as  defined  <rt  efeuse  1 1  (Upper 
Layers  Security)  di  pen  13  of  the  Ol^W  Working  Agreements. 

Suiport  of  ACSi  authenticate^ 

6.2  General  Agreements  on  Users  of  CMIS 

These  agreements  are  based  on  the  standard  defined  in  [CMIS],  [CMIP],  [ADDRMVP]  and  [ADDRMVS] 
constrain  the  users  of  CMIS  services  and  not  the  implementation  of  CMIP  itself. 
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6.2.1  Object  Naming 

Object  Naming  will  be  accomplished  using  Distinguished  Name  or  Local  Distinguished  Name.  Use  of 
nonspecific  form  Is  outside  the  scope  of  these  agreements. 


6.2.2         Multiple  Object  Selection 

Multiple  Object  Selection  applies  to  all  management  operations  except  M-EVENT-REPORT,  M-CREATE  and 
M-CANCEL-GET. 


6.2.2.1  Scoping 

These  network  management  lAs  specify  that  scoping  shall  be  used  as  specified  in  [CMIS]  6.5.1,  8.3.1.1.5, 
8.3.2.1.6,  8.3.3.1.6,  8.3.5.1.5. 


6.2.2.2  Filtering 

These  network  management  lAs  specify  that  filtering  shall  be  used  as  specified  in  [CMIS]  6.5.2,  8.3.1.1.6, 
8.3.2.1.7,  8.3.3.1.7,  8.3.5.1.6. 

If  a  system  receives  a  filter  parameter  that  it  is  unable  to  process,  it  shall  return  the  error  "complexity  limitation", 
including  the  CMISFilter  requested. 

If,  in  the  process  of  filtering  from  a  set  of  selected  entitles,  there  are  no  managed  objects  selected,  the  system 
shall  return  an  empty  response  consisting  of  an  Invoke  ID  and  no  response  argument. 

If  an  Jm{^ementatloR  supports^  Filter  fundtonal  \mh  It  shall  minimally  support  AND  or  OR  with  a  setof 
tmfM&t  00nMQm  {iot  wHch  furfih$r tti^intjof MID  tifOB  CfOn^UCts  is  not  required) ,  and  NOT.  In  addition, 
tfm  impA&nerts^km  ^t^I  support  sending  and  recwv^ng  edi  tBterttem  choices  for  each  filter  condttioa  This 
GJ0Stn$that3i  <5onrfornf^R0  teipl^ftiefttalloftis  not  rec^lred  to  support  compounds  (AND  or  OR)  with  more  than 
tv«>  Items,  arxt  Is  mt  required  to  support  nested  constructs,  Addftlonal  fSter  complexly  may  optiorally  fag 
supported  Mktth6$isa0r$e«i&nt$. 


6.2.2.3  Synchronization 

In  order  to  support  interoperability  between  managing  systems  and  managed  systems,  these  network 
management  lAs  define  that  the  default  synchronization  (i.e.,  BestEffort)  shall  be  supported  by  all  conforming 
systems.  Atomic  synchronization  may  also  be  supported  as  an  option. 

,  If  a  performer  is  unable  to  comply  with  a  synchronization  request  specified  by  an  invoker,  the  performer  shall 
!  return  the  error  "synchronization  not  supported"  with  the  parameter  Indicating  the  synchronization  not 
supported. 
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6.2.2.4  Multiple  Replies 

These  network  management  lAs  specify  the  use  of  multiple  replies  as  specified  in  [CMIS]  7.1 ,  7.2.3. 


 Curront/Evont  Time 

The  time  value  that  is  roportod  to  CMIS,  if  provided,  should  bo  as  oioeo  as  poosiblo  to,  but  not  boforo,  tho 
actual  time  that  the  operation  to  which  the  reported  time  value  applies  ooourrod.  This  constraint  is  stipulated 
to  provide  tho  most  accurate  timostamp  for  temporal  ordering  of  operations  and  events  on  a  single  open 
system. 

For  those  network  management  lAs,  tho  encoding  of  tho  Current  Time  parameters  is  ASM.  1  Generalised  Time, 
UTCType,  as  spocifiod  in  [ASN1  ]  clause  32.3,  b)  and  c),  with  tho  precision  of  tho  time  representation  indicating 
thogranularity  of  thotime  measurement.  For  example,  the  string  10800613123012.333  0600  roprosonts  a  local 
time  of  12:30:12  (and  333  msocs)  on  13th  Juno  1080,  in  a  time  zone  which  is  6  hours  behind  GIVIT. 


6.2.3         Access  Control 

Conformant  implementations  are  not  required  to  use  this  field.  The  Access  Control  field,  if  provided  by  the 
invoker  in  CMIS  request  indicators,  may  be  ignored  by  responding  systems  which  do  not  support  access 
control.  These  systems  shall  not  reject  a  request  on  the  basis  of  the  presence  of  access  information.  The 
invoker  may  interpret  this  as  acceptance  of  the  access  control  parameter. 


6.2.4         CMIS  Funotional  UnitsSub^etS 

Only  tho  Kernel  Functional  Unit  must  bo  supported.  Other  functional  units  except  Extended  Son/ico  are 
optional  and  their  use  shall  be  negotiated  as  spocifiod  in  [CMIS].  Extended  Sorvioo  is  not  within  tho  ccopo  of 
these  agreements.  Negotiation  for  its  "non  uso"  shall  be  supported. 

CuiT^ntty  Ih0  only  way  to  $ubi$^  OMIP  odpat>iliite$  l^througN  CM]^  Fiinoftonal  Uni!$  j[FM$V 


An  Implementation  shali  support  CMIP  FUs  as  Indicated  by  one  ol  the  following  defined  subsets: 
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FUNCTIONAL  UNITS 

Multiple 

"ilil" 

Multiple 
Object 
Selection 

Cancel 

Filt^ 

Extended 
Service 

i 
i 

Basic 

i 

I 

i 

i 

1 

1 
i 

i 

i 

m 

i 

i 

i 

! 

M  «  yancl^ttory         0  *  Optional  VM^^  Scope 


«ach  d$$ooiattDn,  u$e  of  functional  unlt$  $hall  be  negotiated  ^  specified  In  (CMISJ. 


6.3       Specific  Agreements  on  Users  of  CMIS 

These  agreements  are  based  on  the  standard  defined  in  [CMIS]  and  [ADDRMVS].  The  agreements  in  this 
clause  have  been  defined  in  terms  of  those  capabilities  necessary  to  support  the  functions  and  services  defined 
in  clause  5  (Management  Functions  and  Sen/ices)  of  these  agreements.  These  agreements  constrain  the  users 
of  CMIS  services  and  not  the  implementation  of  CMIP  itself. 

The  parameter  presence  information  in  the  tables  in  this  clause  is  repeated  from  [CMIS]  and  has  the  same 
meaning  as  in  the  standard.  It  is  repeated  for  reader  convenience.  In  addition,  these  tables  provide  references 
to  text  clauses  where  agreements  are  stated  relative  to  parameters  in  each  table.  The  lack  of  a  reference 
signifies  no  agreement  beyond  the  base  standard. 


6.3.1  M-EVENT-REPORT 

The  following  agreements  and  clarifications,  pertinent  to  section  8.2  of  the  base  standard  [CMIS]  and  section 
6.3  of  the  base  standard  [CMIP]  and  regarding  the  M-EVENT-REPORT  sen/ice,  are  included  within  these 
network  management  lAs. 

Clause  5  (Management  Functions  and  Services)  of  these  agreements  defines  some  of  the  types  of  Event 
Reports  that  may  be  sent. 

6.3.1.1  Event  Argument 

All  arguments  defined  for  the  particular  event  type  of  the  managed  object  class  (see  clause  7,  Management 
Information  Agreements)  for  the  M-EVENT-REPORT  must  be  supplied  in  the  Event  Argument  parameter.  The 
Event  Information  and  Event  Reply  parameters  shall  be  supplied  as  specified  for  the  event  type. 
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6.3.1.2  Parameter  Agreements 

Conditional  parameters  (C)  siiali  be  included  according  to  the  conditions  defined  in  [CMIS]  unless  those 
conditions  are  refined  by  the  referenced  agreement. 


Table  24|:    M-EVENT  REPORT  Parameters 


Item 

Parameter  Name 

Req/Ind 

Rsp/Conf 

Text  Reference 

1 

lnvoi<e  Identifier 

M 

M(=) 

6.4 

2 

Mode 

M 

3 

Managed  Object  Class 

M 

U 

6.4.5 

4 

Managed  Object  Instance 

M 

U 

6.2.1 

5 

Event  Type 

M 

C= 

6.4.5 

6 

Event  Time 

U 

7 

Event  Information 

U 

6.3.1.1 

8 

Current  Time 

U 

9 

Event  Reply 

- 

C 

10 

Errors 

c 

6.4.4 

6.3.2  M-GET 

The  following  agreements  and  clarifications,  pertinent  to  section  8.3.1  of  the  base  standard  [CMIS]  and  section 
6.4  of  the  base  standard  [CMIP]  and  regarding  the  M-GET  service,  are  included  within  these  networl< 
management  lAs. 


6.3.2.1  Successful  Response 

For  a  successful  M-GET  operation,  the  performer  shall  return  (in  the  Attribute  List  parameter)  either  the  attribute 
values  for  all  attributes  explicitly  requested  (in  the  Attribute  Identifier  List  parameter),  or  the  attribute  values  for 
all  attributes  defined  for  the  managed  object(s)  selected  (if  the  Attribute  Identifier  List  is  omitted). 


6.3.2.2  Partially  Successful  or  Unsuccessful  Response 

For  a  partially  successful  M-GET  operation,  where  only  some  attribute  values  were  retrieved,  the  performer 
shall  return  (in  the  Errors  parameter,  specifically  encoded  as  GetListError)  all  attribute  ids  and  their 
corresponding  values  that  were  successfully  retrieved  from  the  set  of  attributes  selected  as  described  above, 
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together  with  all  attribute  ids,  and  the  corresponding  error  codes,  for  each  of  the  attributes  for  which  errors 
were  detected.  All  attributes  requested  by  the  invoker  must  be  processed,  with  either  a  value  or  an  error  code 
returned  for  each. 


6.3.2.3  Multiple  Replies 

For  the  final  reply  of  a  series  of  multiple  relies  or  the  single  reply  where  no  objects  were  selected  when  filtering 
has  been  specified,  the  GetResult  is  omitted.  Hence  Managed  Object  Class,  Managed  Object  Instance, 
Current  Time  and  Attribute  List  are  all  omitted  in  these  cases. 

6.3.2.4  Parameter  Agreements 

Conditional  parameters  (C)  shall  be  included  according  to  the  conditions  defined  in  [CMIS]  unless  those 
conditions  are  refined  by  the  referenced  agreement. 

Table         M-GET  Parameters 


Item 

Parameter  Name 

Req/Ind 

Rsp/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M(=) 

6.4 

2 

Linked  Identifier 

C 

6.4 

3 

Base  Object  Class 

M 

6.4.5 

4 

Base  Object  Instance 

M 

6.2.1 

5 

Scope 

U 

6.2.2.1 

6 

Filter 

U 

6.2.2.2 

7 

Access  control 

U 

6.2.3 

8 

Synchronization 

U 

6.2.2.3 

9 

Attribute  Identifier  List 

U 

6.4.5 

10 

Managed  Object  Class 

C 

6.4.5 

11 

Managed  Object  Instance 

C 

6.2.1 

12 

Current  Time 

U 

13 

Attribute  list 

C 

6.4.5,  6.3.2.1,  6.3.2.3 

14 

Errors 

c 

6.3.2.2,  6.4.4 

't 
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6.3.3 


M-SET 


The  following  agreements  and  clarifications,  pertinent  to  section  8.3.2  of  the  base  standard  [CMIS]  and  section 
6.5  of  the  base  standard  [CMIP]  and  regarding  the  M-SET  service,  are  included  within  these  network 
management  lAs. 


For  a  suGCOSsful  M  SET  confirmed  operation,  tho  porformor  shall  return  (in  the  Attribute  List  paramotor)  tho 
attribute  values  for  all  attributes  oxplioitly  spocifiod  (in  the  Attribute  List  parameter)  indicating  thoir  now  values. 


For  a  partially  successful  M-SET  operation,  where  only  some  attribute  values  were  modified,  the  performer  shall 
return  (in  the  Errors  parameter,  specifically  encoded  as  SetListError)  all  attribute  ids  and  their  corresponding 
values  that  were  successfully  modified  from  the  set  of  attributes  ids  and  values  supplied,  and  all  attribute  ids 
and  the  corresponding  error  codes  for  each  of  the  attributes  for  which  errors  were  detected.  All  attributes 
requested  by  the  invoker  must  be  processed,  with  either  a  value  or  an  error  code  returned  for  each. 


6.3.3.2  Multiple  Replies 

For  the  final  reply  of  a  series  of  multiple  relies  or  the  single  reply  where  no  objects  were  selected  when  filtering 
has  been  specified,  the  SetResult  is  omitted.  Hence  Managed  Object  Class,  Managed  Object  Instance,  Current 
Time  and  Attribute  List  are  all  omitted  in  these  cases. 


6.3.3.3  Add/Remove  Response 

Where  multi-valued  attributes  are  involved  in  an  M-SET  operation  [ADDRMVS],  the  values  returned  after  any 
modification  operation  must  be  the  full  set  of  values  of  that  attribute  and  not  just  the  values  that  were  modified 
(e.g.,  added  or  removed). 


6.3.3.4  Parameter  Agreements 

Conditional  parameters  (C)  shall  be  included  according  to  the  conditions  specified  in  [CMIS]  unless  those 
conditions  are  modified  by  the  referenced  agreements. 


6.3.3.1 


Successful  Response 


6.3.3.1 


Partially  Successful  or  Unsuccessful  Response 
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Table  2311:  M-SET  Parameters 


item 

Parameter  Name 

Req/Ind 

Rsp/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M(=) 

6.4 

2 

Linked  Identifier 

- 

C 

6.4 

3 

Mode 

M 

- 

4 

Base  Object  Class 

M 

- 

6.4.5 

5 

Base  Object  Instance 

M 

- 

6.2.1 

6 

Scooe 

u 

6.2.2.1 

7 

Filter 

u 

6.2.2.2 

8 

Af!CPSi>  control 

u 

6.2.3 

9 

Synchronization 

u 

6.2.2.3 

10 

Managed  Object  Class 

c 

6.4.5 

11 

Managed  Object  Instance 

c 

6.2.1 

12 

Modification  List 

M 

6.4.5,  6.3.3.1,  6.3.3.3, 
6.3.3.4 

13 

Attribute  List 

u 

6.4.5.  6.3.3.1,  6.3.3.3 

14 

Current  Time 

u 

15 

Errors 

c 

6.3.3.2,  6.4.4 

6.3.4  M-ACTION 

The  following  agreements  and  clarifications,  pertinent  to  section  8.3.3  of  the  base  standard  [CMIS]  and  section 
6.6  of  the  base  standard  [CMIP]  and  regarding  the  M-ACTION  service,  are  included  within  these  network 
management  lAs. 

6.3.4.1  Multiple  Objects 

When  multiple  objects  are  selected  for  an  M-ACTION  operation,  there  is  no  ordering  implied  among  selected 
objects. 
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6.3.4.2  Parameter  Agreements 

Conditional  parameters  (C)  shall  be  Included  according  to  the  conditions  defined  in  [CMIS]  unless  those 
conditions  are  modified  by  the  referenced  agreements. 

Table  2412:  M-ACTiON  Parameters 


Item 

Parameter  Name 

Req/Ind 

Rsp/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M(=) 

6.4 

2 

Linked  Identifier 

C 

6.4 

3 

Mode 

M 

- 

4 

Base  Object  Class 

M 

- 

6.4.5 

5 

Base  Object  Instance 

M 

- 

6.2.1 

6 

Scope 

U 

- 

6.2.2.1 

7 

Filter 

U 

6.2.2.2 

8 

Managed  Object  Class 

C 

6.4.5 

9 

Managed  Object  Instance 

c 

6.2.1 

10 

Access  control 

U 

6.2.3 

11 

Synchronization 

U 

6.2.2.3 

12 

Action  Type 

M 

C(=) 

6.4.5 

13 

Action  Information 

U 

14 

Current  Time 

u 

15 

Action  Reply 

c 

16 

Errors 

c 

6.4.4 

6.3.5  M-CREATE 

The  following  agreements  and  clarifications,  pertinent  to  section  8.3.4  of  the  base  standard  [CMIS]  and  section 
6.7  of  the  base  standard  [CMIP]  and  regarding  the  M-CREATE  service,  are  included  within  these  network 
management  lAs. 
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6.3.5.1  Managed  Object  Instance 

The  Managed  Object  Instance  request  parameter  may  be  present  or  absent  depending  on  whether  the  invoker 
supplies  the  instance  name  or  the  performer  assigns  the  Instance  name  automatically.  The  definition  of  each 
Managed  Object  Class  specifies  whether  or  not  this  parameter  must  be  present.  This  definition  shall  apply  to 
every  management-initiated  creation  of  instances  of  that  managed  object  class. 


6.3.5.2  Attribute  Values 

The  values  of  each  of  the  attributes  of  the  newly  created  object  are  derived  as  defined  in  [MIM]  5.2.2. 1 .  If  none 
1    of  these  methods  provides  a  value  for  any  one  attribute,  then  the  operation  shall  be  considered  to  have  failed, 
I.e.,  no  new  instance  Is  created,  and  the  error  code  'Missing  Attribute  Value'  shall  be  returned. 


6.3.5.3  Parameter  Agreements 

Conditional  parameters  (C)  shall  be  included  according  to  the  conditions  defined  in  [CMIS]  unless  those 
conditions  are  modified  by  the  referenced  agreement. 


Table  2511:  M-CREATE  Parameters 


Item 

Parameter  Name 

Req/Ind 

Rsp/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M(=) 

6.4 

2 

Managed  Object  Class 

M 

C 

6.4.5 

3 

Managed  Object  Instance 

U 

C 

6.2.1,  6.3.5.1 

4 

Superior  Object  Instance 

U 

6.2.1 

5 

Access  Control 

U 

6.2.3 

6 

Reference  Object  Instance 

U 

6.2.1 

7 

Attribute  List 

U 

C 

6.4.5,  6.3.5.2 

8 

Current  Time 

U 

9 

Errors 

c 

6.3.5.2,  6.4.4 

6.3.6  M-DELETE 

I  The  following  agreements  and  clarifications,  pertinent  to  section  8.3.5  of  the  base  standard  [CMIS]  and  section 
6.8  of  the  base  standard  [CMIP]  and  regarding  the  M-DELETE  service,  are  included  within  these  network 
management  lAs. 
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6.3.6.1  Deletion  of  Objects  Containing  Objoots 

The  error  'ProoosGing  Failure'  shall  bo  roturnod  tf  a  managed  objoot  has  oxlGting  oontainod  objects  and  tho 
behavior  dofinod  for  that  object  prohibits  its  deletion  unless  all  contained  objects  have  boon  doloted. 

6.3.6.1  Parameter  Agreements 

Conditional  parameters  (C)  shall  be  included  according  to  the  conditions  defined  in  [CMIS]  unless  those 
conditions  are  modified  by  the  referenced  agreements. 

Table  2614:  M-DELETE  Parameters 


item 

Parameter  Name 

Req/Ind 

Rsp/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M(  =  ) 

6.4 

2 

Linked  Identifier 

C 

6.4 

3 

Base  Object  Class 

M 

6.4.5 

4 

Base  Object  Instance 

M 

6.2.1 

5 

Scope 

U 

6.2.2.1 

6 

Filter 

u 

6.2.2.2 

7 

Access  control 

u 

6.2.3 

8 

Synchronization 

u 

6.2.2.3 

9 

Managed  Object  Class 

C 

6.4.5 

10 

Managed  Object  Instance 

C 

6.2.1 

11 

Current  Time 

U 

12 

Errors 

C 

6.3.6.1,  6.4.4 

6.4       Specific  Agreements  on  CMIP 

These  agreements  are  based  on  the  standard  defined  in  [CMIP]  and  [ADDRMVPj.  The  agreements  in  this 
clause  have  been  defined  in  terms  of  those  capabilities  necessary  to  support  the  functions  and  services  defined 
in  clause  5  (Management  Functions  and  Services)  of  these  agreements. 

These  network  management  lAs  make  no  agreements  beyond  the  specifications  in  [CMIP]  and  [ADDRMVP], 
except  the  following: 
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6.4.1  Invoke/Linked  Identifier  Size 

Invoke  Identifiers  and  Linked  Identifiers  must  be  encoded  in  an  integer  of  four  (4)  octets  maximum  length. 

6.4.2  Version 

Protocol  Version  2  (only)  is  supported. 

6.4.3  Linked  Reply  Values 

Responders  must  send  a  linked  reply  value  that  corresponds  to  the  original  invoke  operation  value. 

6.4.4  Error  Codes 

Responders  must  send  error  types  that  correspond  to  the  operation  definition  for  the  original  invoke. 

6.4.5  Parameters 

The  CMIP  globalForm  shall  be  supported  for  the  following  parameters: 

ActionTypeld 
Attributed 
EventTypeld 
ObjectClass 

Use  of  localForm  is  outside  the  scope  of  these  agreements. 

In^^entatior^  stell  receive  all  forms  of  all  ASN.  1  CHOICE  types  and  values  defined  in  [CMIP].  Receipt  sl^ 
require  pas$ingth^  value  to  the  CMIS  user, 

6.4.6  Acc«»s  Control  Parameter 

ftn  implementatior!  shall  be  able  to  send  the  accessControl  parameter. 
6.5       Services  Required  by  CMIP 

CMIP  requires  the  sen/ices  provided  by  ACSE  and  ROSE.  The  conformance  requirements  for  these  sen/ices, 
and  the  underlying  communication  required  to  support  them,  are  specified  in  part  5,  subclause  13.7. 
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ACSE  Functional  Units:  Kernel 
6.6        CMIP  PICS 

(Refer  to  the  Working  Implementation  Agreements  Document.) 


7  Management  Information 

This  olauso,  which  is  based  on  ISO  standards'  dooumonts  [MIM]  and  [GDMO],  oontainGagroomonts  regarding 
basic  conoopts  and  modelling  tochniquos  rolatod  to  managomont  information.  It  onumoratos  agroomonts  on 
(i)  the  information  model  (subclause  7.1),  (ii)  principles  for  naming  managed  objects  and  their  attributes 
(subclause  7.2),  and  (iii)  guidolinos  for  defining  managomont  information  (subclause  7.3).  It  is  not  within  the 
scope  of  this  clause  to  make  agroomonts  about  specific  elements  of  management  information  or  to  define 
such  specific  elements  of  managomont  information.  Such  definitions  and/or  agreements  can  bo  obtained  via 
the  Managomont  Information  Library  (IVIIL)  produced  by  the  OSI  MIB  Working  Group  (  a  subgroup  of  the 
NMSIG). 


TtI  The  Information  Model 

This  subclause  contains  agroomonts  rolatod  to  the  information  model  as  specified  in  clause  6  of  [MIM]. 


774t4  inhoritanoo 

! 

The  following  constraint  rolatod  to  inheritance  is  enforced  in  ordc  to  remove  potential  ambiguities: 

During  the  lifetime  of  a  managed  object  instance,  each  of  its  attributes  must  have  a  value  that  is 
valid  for  tho  attribute  syntax  of  that  attribute. 


774t2  Allomorphiom 

Allomorphism,  as  specified  in  clause  6. 1.3  of  [MIM],  is  not  supported.  Any  other  specif ication  within  the  [MIM] 
or  [GDMO]  that  refers  to  allomorphism  is  also  not  supported.  "Not  supported",  in  this  context,  moans  that  an 
implementation  that  complies  with  tho  NMSIG  lAs  is  not  required  to  implement  allomorphism. 


7t4,3  Rfter- 

The  concept  of  filter  is  supported  as  specified  in  clause  6.3  of  [MIM].  Restrictions  on  its  usage  are  cpocifiod 
in  subclause  6.2.2.2  and  subclause  6.1.3.2  of  those  agreements.  The  restrictions  in  subclauce  6.2.2.3  are 
applicable  when  tho  implementation  is  using  "pure"  CMIS.  If  tho  implementation  is  using  sorvices  of  the  System 
Management  Functions  specified  in  clause  6.  the  filter  restrictions  spocifiod  in  subclause  5.1.2.1  apply. 
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7^2  Prinoiplos  of  Naming 

This  oubolauGO  oontaino  agroomonto  about  principloo  of  naming  ac  opooifiod  In  olauoo  6  of  [MIM], 
 Name  Structure 


7.2.1.1  Objoct  Class  Idontification 

A  managed  object  olaco  io  idontifiod  by  an  ASN.1  objoot  idontifior.  ao  Gpooifiod  in  olauoo  6.3.1  of  [MIM]. 

7.2.1.2  Object  Instance  Idontification 

The  diotinguiohod  name  approach  io  used  for  tho  idontification  of  managed  objoot  inotanooG,  as  Gpooifiod  in 
olauoo  6.3.2  of  [MIM]. 


7.2.1.3  Attribute  Identification 

Each  individual  attribute  of  a  managed  objoct  io  idontifiod  by  an  ASN.1  objoot  identifier,  ao  Gpooifiod  in  olauoo 
6.3.1  of  [MIM]. 


7.2.1.4  Managed  Object  Knowledge 

Dynamic  charing  of  managomont  knowlodgo  io  not  oupportod.  However,  all  attributoG  related  to  oharod 
management  knowledge  are  containod  in  tho  managed  objoot  olaoo  "top",  which  io  dofinod  in  [DM!] .  Since  all 
managed  object  cIogg  definitions  in  tho  MIL  are  derived  from  "top"  ao  defined  in  [DMI],  thooo  managed  objoot 
olaoooG  will,  by  definition,  contain  tho  management  knowledge  attributoG. 

Since  AllomorphiGm  io  not  Gupportod,  the  Allomorphic  SupcrclaoGOG  attribute,  which  io  one  of  tho  attributoo 
defined  in  "top",  will  have  ao  ito  value,  the  OBJECT  IDENTIFIER  of  the  managed  objoot  olaoo  to  which  it 
belongo. 


7^  Guidollnos  for  tho  Definition  of  Managomont  Information 

Thio  oubclauoG  oontaino  agroomonto  about  guidolinoo  for  the  definition  of  management  information,  ao 
speoified  in  [GDMO].  Thooo  guldollnoo  apply  to  dovoloporo  of  contributiono  to  tho  Managomont  Information 
Library.  They  form  a  normative  part  of  tho  otandard;  honco  thoy  muot  bo  otriotly  followed  whilo  defining 
managomont  information. 
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JiZri  Syntaotical  Definitions  of  Managemont  Information 


7.3.1.1  Managed  Object  Class  Template 

Tho  ALLOMORPHIC  SET  construct  of  tho  Managed  Object  Class  Template  spocifiod  in  clause  10.3.2  of 
[GDMO]  is  not  supported.  "Not  supportod",  in  this  context,  moans  that  no  managed  object  class  definition  in 
the  Managemont  Information  Library  will  contain  this  construct. 


7.3.1.2  Pookago  Template 

The  following  constraints  apply  to  the  Package  Template  specified  in  clause  ^0.A.2  of  [GDMO]: 

For  the  ATTRIBUTE  GROUPS  construct,  new  attributes  shall  not  be  added  to  the  group  attribute 
from  within  the  managed  object  class  template  because  this  can  lead  to  ambiguities.  Hence,  tho 
[< attribute  label  >]  portion  of  tho  supporting  definition  for  the  ATTRIBUTE  GROUPS  construct  shall 
not  be  uoed. 

The  REGISTERED  AS  construct  shall  bo  mandatory. 


7.3.1.3  Attribute  Template 

The  following  constraint  applies  to  the  Attribute  Template  specified  in  clause  10.7.2  of  [GDMO]: 

The  BEHAVIOUR  conctruct  may  bo  omitted  only  if  a  behaviour  definition  has  been  inherited  from 
the  parent  attribute,  i.e.,  the  attribute  is  derived  from  another  attribute  whose  definition  contains  a 
BEHAVIOUR  conctruct. 


7.3.1.4  Attribute  Group  Template 

For  the  ATTRIBUTE  GROUP  to  bo  useful,  it  is  rocommondod  that  tho  GROUP  ELEMENTS  construct  be  precont. 


Ts^^a  Guidelines  For  Defining  Behaviour 

The  following  details  shall  be  provided  in  the  sot  of  spocificationc  defining  a  managed  object  class: 

 a  textual  description  of  tho  network  resource  the  managed  object  class  represento.  including 

its  functional  role. 

 a  description  of  tho  relationships  that  can  occur  between  different  instances  of  the  managed 

object  class  being  defined,  as  well  as  those  that  can  occur  between  instances  of  the  managed 
object  class  being  defined  and  instances  of  other  managed  object  classes. 
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a  doscription  of  tho  oporationc  that  aro  cupportod  by  tho  managod  objoot  claGc,  with  procioo 
dofinition  of  tho  offoctc.  cido  offoctc  if  any,  conctraintG,  rocponoo  notificationo,  failuro  modoo. 

spooification  of  how  instanooc  of  this  managod  objoct  claoc  aro  croatod  and  dolotod,  partioulaily 
whothor  thoy  can  bo  croatod/dolotod  via  tho  managomont  CREATE/DELETE  oporationo. 

a  doscription  of  notificationo  that  can  bo  gonoratod,  tho  conditione  that  gonorato  thorn  (o.g., 
orosoing  of  a  throchold).  their  oontonto  and  cido  offoots,  if  any.  In  particular,  identify  all  tho 
attrlbutoG  that  aro  cubjoct  to  the  AttributeChango  and  StatoChango  notificationo,  if  theoo 
notifloations  aro  supportod. 

other  oonstrainte,  including  those  involving  other  managod  objoct  claocoG. 


7^9^  Other  Guidelines 

Tho  Systoms  Managomont  functions  have  defined  various  attributes  and  ovontc,  as  indioatod  in  clauGO  6  of 
thoso  agroomonto.  Objoot  dofinors  shall  make  use  of  these  attributes  and  ovonto  wherever  applicable. 


Tidr^  Initial  Value  Managed  Objects  (IVMO) 

Tho  following  text  olarifios  underlying  concepts  of  Initial  Valuo  Managod  Objects  (IVMOs)  specif iod  in  clauoo 
8.7of  [GDMO]: 

Initial  Value  Managod  Objects,  described  in  clauso  8.7  of  [GDMO],  aro  most  usoful  in  cases  whore 
managod  object  classes  that  do  not  support  tho  CREATE  operation  have  boon  defined.  Instanoos 
of  such  objoct  classes  would  bo  created  as  a  result  of  the  normal  operation  of  tho  network,  but  it 
may  bo  desirable  to  bo  able  to  control  the  initial  values  of  attributes  of  now  instances  of  such  objoct 
classes  via  managomont. — IVMOs  provide  a  mechanism  to  do  this. — The  NMSIG  Transport 
Connection  Profile  managod  object  class  defined  in  the  MIL  is  an  example  of  an  IVMO. — It 
represents  the  collection  of  charactoristic  attributes  that  supply  default  and  initially  advertised 
attribute  values  to  be  usod  by  instances  of  tho  NMSIG  Transport  Connection  managod  object  class 
when  the  instances  aro  created.  Since  the  NMSIG  Transport  Connection  managed  objoot  class 
does  not  support  the  management  CREATE  operation,  this  IVMO  servos  as  a  mechanism  which 
allows  initial  values  of  attributes  of  instances  of  tho  NMSIG  Transport  Connection  managod  objoct 
class  to  bo  controlled  by  management. 

7      Management  Information 

This  clause,  which  Is  based  onlSO  standards' documents  fMtM]and  [GDMO],contalnsagreementsfeprd!ng 
basic CohC^pts unci  modetling  techniques  related  to  management  information.  It  enumerates  agreements  on 
^)  the  Information  mcxlel  (subclause  7,1)  and  (li)  guidelines  for  defining  management  information  (subdause 
7.2)v  thes^  agrei^en^a  apply  to  developers  of  contributions  to  the  Management  Information  Library  (MIL). 
They  form  a  normative  part  of  the  standard;  hence  they  must  be  strictly  followed  wh8e  defining  management 
Normatiort.  U  is  not  within  the  scope  of  this  clause  to  make  agreements  aboul^  ^jedfic  elements  ^ 
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and/oragreemenks  <sm  be  obtained  via  the  Management  information  Ubraryx 


7,1       Tli^  liiformatfon  Moder 

When  iTiOdeBinQtmrtageirientmforiTTatloa,  these  agrees  wththefoSOwirig  addJtioriat 


7*1*1  intterttanee 

The  foBoWirt9  oort^ralnt  related  to  inheritance  is  enforced  b  order  to  remove  potential  ^*Tit?l0u^e« 

During  th^  iUetinTe  of  a  maraged  obfect  Instance,  each  of  It^  attribtlte^  must  haive  d  value  that  1$ 
\«lid:*QP;;thie:::attrlbute  syntax  of  that  attribute. 


7.1^  iivteroper^bitity 


7.1*2.1  InkffiropwablUty  Provided  By  The  A^enl  System 

AKomorphlsm^assped^d  In  clauses  2  3 1  of  [UM],  is  out <^ scope.  Anyo^r^cl5ca^n«^Nnthe  [MUl 
Of  (ODMOI  that  refers  to  allomorphism  is  also  out  of  scope. 


7.1.^2         liit«'opcH^|]^ility  Provided  By  The  Manager  System 

The  ssmanttes  of  clause  5,2.3.2  of  [MM]  are  supported.  A  manager  system  can  ^  <^ect  identic 
as  $ped^6d  in  daus^  7-4,5  of  [GDMO]  to  specify  that  a  managed  object  should  perform  ah  operation  as  a 
member  of  its  actuai  class.  The  object  identifier  Is  Intended  to  be  used  \n  reqiiest^  oitfy,  and  shall  be 
Nerpreted  by  ^e  reSpwder  as  a  requirement  to  return  its  real  object  class  ValUfeljI^thft:*^  Ag^eitt 
s^tenjs  shail  support  thJs  object  identifier  as  defined  in  [MlMj  5.2.3.2  and  [GDMO]  7AJSh 


7.1^  Filter 

The  oono^of  i&supported  as  specified  in  clause  6.  Pestrlctiws  w  fts^ usage  are  s^ec^Bed  m  subdause 
BJi.Z2  of  ^lese  agreements; 


7.1.4        Manademeni  operations 

An  impiemer^ie^  ©lat  compiles  with  these  agreements  shall  support  maragenient  {^rations  as  defined  ih 
diause  5.3.4  df  {UM]  wISi  the  fdllowing  additional  claiiftcation. 
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pwij  olau$e  $.3,4.t  (2).  [DU\]  clause  6.t4,  and  fGDMO)  clause  6.1.4  Imply  fih^  the  object 
attrtbi^eshail  not  be  included  in  thie  create  request  Attribute  Ust  parameter.  [MJMJ  states  that  any 
coBfiltstir^  <iupltoate  specifications  cause  th$  request  to  fait 


7 AS         Deletion  of  Objects  Containing  Objects 

TItb  error  'Proces^ng  Failure'  shall  be  returned  tf  a  managed  object  has  existing  contained  objects  and  tfie 
b^vlor  defined  fortfiait  object  prohibits  its  deletion  unless  all  contakiecl  objects  have  been  deleted*. 


yjZ      Ouldellnes  lor  the  Definition  of  iManagement  rnformatloii 

TWs  st^JEteusB  contetns  agreements  about  guidelines  lor  the  definition  of  management  information,  ^ 
spi6(g8iedin(GDMO|j 


7.2.1         S^l^<^cal  Definitions  of  l\Aanagement  Informatltm 


i  7^^j        Attribute  Template 

^    Tiie  fdlowing  constraint  applies  to  the  Attribute  Template  specified  in  clause  9  J, 2  of  (GDMOJl 

Hie  BEHAViOUi^  construct  may  be  omitted  oriy  If  a  betevlour  definition  has  been  inherited  from 
ti!JB:5P2B!erft:ial»:lbute,  I.e..  the  attribute  is  derived  from  another  attribute  whose  definition  contains  a 
aEHAVlOUB  construct 


iJUt         Guidelines  For  Defining  Behaviour 

The  fdlovs^g  details  should  be  provided  in  the  set  of  specifications  defining  a  managed  ob|ect  classi 

*  a  textual  description  of  the  network/system  resource(s)  ihe  managed  oiafect  class  re}>resems» 
indydlhg  ^eir  functional  role;*: 

-  a  deeoriptlon  of  the  relationships  that  can  occur  between  different  Ihstswcee  of  ^  managed 
i^mt  class  being  defined,  as  well  as  those  that  can  occur  between  instances  of  the  manage^ 
C^ect  dass  being  dePned  and  instances  of  other  managed  object  classes, 

-  a  dest^lpticwi  of  the  operations  tliat  are  supported  by  the  nonaged  object  class,  with  precise 
defiritlon  of  the  effects,  side  effects  if  any,  constraints,  response  notifications,  faiure  modes. 

«  sp©daica«on  of  hovr  Irvstances  of  this  managed  object  class  are  created  and  deleted,  partlculartsf 
Whether  they  can  be  created/deleted  via  the  management  CReATE/OElfTE  operations. 
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a  desci-iptlon  < 

)f  notiflcatlons  that  can  bd  gdneratod,  the  < 

;onditrons  that  generate  them  {&g.. 

crossmg  of  a  1 

hreshdd),  their 

contents  and  stde-effects, 

If  any>  In  particular^  Identify  all  the 

i3^rll)(tf0$::  ::M  are  subfect 
ndE^ca^ons  are  supports 

to 

the  AttributeChange  mi 

StateChange  noti^tions,  g  these 

-    c*her  constraints,  Indliidlng  those  involving  other  managed  direct  classes. 


7v2,3        Other  OuMeiine^ 

Th9  $y$tei!n$^  ^»a9^em$nt  functions  have  defined  variou$  attribut$$  d»d  a$  I»di03t9ci^  tn  <ilaM$e  ^  of 
these  agreoTwrts,  Object  definers  shoi^  make  use  <rf  these  attributes  and  events  whaiever  appllcaWe< 


S  Conformance 


8,1  Introduction 

C^us©  8  spec^  the  conformance  requirements  for  the  OIW  Networlr  Managemem  ImirfenE^efitatlon 
Agreemwits  (lAs).  tn^CTnentors  of  products  will  provide  claima  erf confornianceto these requlrenients*  thesa 
claims  will  be  In  the  form  of  Protocol  Implementation  Conformance  Statements  <PICS)  and  Managed  ObJecS 
Confomiance  Statwients  (MOCS).  These  requirements  wil  also  be  used  todev^op  lest  whlc^iwilt  be 
used  ID  vaSdisdte  claims  of  conformance.  This  clause  defines  the  generat  carScgmsim  raqiJrements  and 
criteria  which  ^8  be  used  as  a  basis  for  tests  of  implementations  ctaimtng  cofifotmartce  tothi^agreement8> 
Dependent  conformance  requirements  are  defined  In  the  context  in  which  they  are  used  (&g.,  8MF  gener^ 
conformance  raijulrwients  Indude  CM  IP  dependent  conformance  requirements  for  C^tS  8^kjes  Used), 

(F?efer  to  the  Working  Implementation  Agreements  Document  for  additional  Jntrodudory  text) 


8.2      Gejuerai  Requirements  of  Conformance 

Confonmancefor  these  agreements  Is  designed  to  specify  a  well-defined  set  of  niarjagememcapabiltles  and 
features-  Porthe|>urposes  of  organization  and  darfty  of  these  agreements,  n»nagert»ent  has  baeri  divided 
Into  tfvee  cantegortBS.  Clauses  5  (Management  Functions  and  Services),  6  <Managemem  Communications) 
and  7  (Maiiagorrient  Information)  state  the  agreements  which  respectively  comprise  Ihree  Cionformanca 
t^egories.  Within  these  categories,  particular  conformance  categories  are  speeded  whidh  delineate 
conloffinarwereqiBrenTentsfor  a  well-defined  and  bounded  set  of  mar^gemer^  capabilities  arid  features  <e.g., 
withtin  die  Management  Functions  and  Services  confomaance  categories,  a  conformance  category  Is  specified 
wfiich  defines  oor^^^mance  to  Alarm  Reporting  and  State  Management  Services),  OrKje  a  conformance 
category  Is  d^ln^ed  which  specifies  the  set  of  requirements  for  that  category,,  tests  can  be  dev^oped  to 
evaluate  conforfnar»oe  of  products  to  that  conformance  category.  An6  finally^  fc^"  sorne  oonformar«j0 
categories^  rcfes  (Manager,  Agent,  or  both)  are  specified.  One  or  more  roles  ntay  be  sufp»ted  f<y  those 
it^onformariCe^iCategorles  to  whicfi  an  implementation  is  conformant 
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Th0  <lfiv^opm$«t  i3l  oottformanoe  <jategorle$  will  $naW0i 

1)  u$m  to  d^line  procurement  $p0clfloatlotis. 

2)  vertdOf$  to  define  flnati^gem^nt  capai>aiti$$  and  featur0$; 

3)  oonlormenoQ  lest  housee  end  othei^  to  define  te9t  im&a, 
Tol>eoo»iomi^iothe^^  animpieraenteyon  $h$ilbe  oonrormantto^lee$ton0Of  DiefolloW&igMI^^^ 

0   Management  Communication 

0   Managenftent  Funotlone  and  Services 

0  Mana9ement  Iniomnatlon 

IfT^emenlatloas  which  are  eonfontiant  to  these  categories  shall  comply  with  the  requirements  stated  In  the 
follawin^  clause^; 

8.3       Sp(dcil{<;  Conformance  Categories 

Management  Oommunteation  Categories 

To  ise  oonfortmni:  to  the  JVIanagement  Communication  categories,  an  implementation  shall  conform  to 
agreemwts  inolause6»  Cortforrnance  to  management  communication  also  requires  an  implementorto  state 
which  el  ttie  management  communication  profiles  specified  In  clause  6  are  supported  In  the  Imfrf^nentation. 
The irt^jiem^or** statement  of  whicti  profSe  is  supported  shalt  be  indicated  in  a  CMIP  PICS  as  follows.  The 
implemeiitor  8h£^  con^plete  the  PiCS  prof orma  as  specified  by  one  of  tim  profiles  specified  in  dau&e 

Hole:   tConlcH'mance  requirements  fc*  Shese  lAs,  relating  to  services  required  of  the  upper  layers  and  other 
AS^srare  discussed  in  part  5i  clause  1 3.7] 

Management  Functions  and  Servlcee  Conformance  Categorlee 

{ftefer  lotheW<»kbig  Implementation  Agreements  Document.) 

8.a.a.1  General  Management  Capabilities  Conformance  Category 

{Refer  tothe  Wwking  Implementation  Agreements  Document.) 
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Alarm  R^rttug  amt       Mdmigemeftt  Capabltilteft  Conformttnoa  Cal^ory 
{f{$/t^t  10  th0  Working  Impr^mentatlor)  Agr6dm$nt$  Dooum^tit) 


AJarm  jReportfng  Capabilities  Conlormanca  Category 

Pefer  to  the  Working  I  mplementation  Agreements  Docufwenl| 


8.3.2.4         General  Event  Report  Ma naQemet^^ 
{Hefer  toth^  Working  Implementation  Agreements  Document.) 


Qanarat  Log  Contr(^  Conformance  GategcMy 

(Refer  totNe  Warkmg  Implementation  Agreements  Dociiment) 


0,3^        Management  information  Conformanoe  Category 

To  be  oontormant  to  Ste  Management  Information  Conformance  Category, ^  lmplementaitlc»n  shafi  incliide 
at  lea^  one  managed  object  defined  as  specified  by  clause  7.  The  requirements  for  managing  ^ismanag«j 
object  $hail  ncA  oonflict  with  the  specifications  In  clauses  5  and  6.  Mar^gect  <^eot  da$d  de6i^lQn$  ^tl  be 
provided  eitberinftid  or  by  reference.  Registered  object  identifiers  shall  be  associated  wftlianysuclimaiiage<f 
object  c^a$e {IMtlon  and  supporting  definitions  {e.g.,  attributes,  name  l^lng$).  Ait  m^atory  abetmct 
syntaxes  and  semantics  associated  witli  those  identifiers  shall  be  used*  Note  ttetaJI  managed  objects  are! 
supporting  di^teifions  In  Annex  A  satisfy  these  conformance  requlrementSii; 

An  Impien^ntate  1$  conformant  to  a  managed  object  class  definition  If  ft  suppori$all  the  mandatory  packsiQ6$ 
specified  in  the  nonaged  object  class  as  well  as  all  associated  information  (e<g,>.  at^l»ii»s^  Relocations, 
actions,  parameters)  referenced  in  these  packages  and  at  least  one  name  binding  that  may  beusedtO^Wpport 
the  naming  of  instances  of  this  managed  object  class.  Although  it  is  not  necessary  to  be  o<ynfonrnam  ID  all 
euperior  ol^eotolasee^  In  the  containment  tree  of  an  Instance  of  a  conformant  managed  obj0(^<:^$$,  ^  name 
bindings  and  r»mlng  attributes  necessary  to  access  that  object  instance  shall  be  putjiicly  smiisiM* 


The  Implementor  shall  provkie  a  statement  specifying  which  managed  objeotolasaes  are$U|^Xi^ed.  AMQCS 
protorma  shall  be  completed  by  the  implementor  for  each  managed  ok^ect  dass  suppoiteEi 

Editor's  Note:  [The  CD  Version  of  ISO/lEC  10165-6  (Requirements  and  Guidelines  for  Implemwita^on 
Conformance  Statement  Proformas  Associated  with  Marwgemer^  infomiaMon)  is  now 
available.  MOOS  Proformas  for  each  managed  object  class  supported  sbotUd  bedeveloped 

ilnsistent  with  10165-6  IMOCSJ.J 
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For  each  man^Qed  object  o1a$$  $upported,  th$  f<M<Mn^  $|td)l  b9  $1^10(1 

0......,,^^^^  attribute  valu^/mnges,  InlSal  values)' fOppt^ 

unless  socli  constraints  are  defined  in  tiie  managed  ofciject  ciass  definition; 

o  a  a^^ 

0   a  statement  of  role(s)  (manager,  agent,  or  both)  in  which  the  ol)|e(^  class  de^ 
edH0f*t  Note  iW  10165-6  does  not  cun^^ty  distln^tiift  rplll 
6.14         Management  Application  Contexts 

Tha  Implementation  sliall  support  at  least  the  application  context  for  systems  management  defined  in  ISO/tEC* 
Hole:   t^uch  a  statement  Is  required  by  [SMOJ  clause  7.2| 

Ifote:   [Stidh  a  slatemem  Is  required  by  part  5,  clause  t^J^  tA^tch  di€tcusses  conformance  reqiAwr»n^ 
forihesff  lAsrw  related  to  $e(A/i0es^^t^^^        the  iJpper  layers  and  other  ases.| 

84      Demonsiration  of  Conformance 

^efer  tothe  Wcxrking  implementation  Agreements  Document.) 

8.4.1  Management  Communication 

(Refer  to  the  Wofkftig  Implementation  Agreements  Document) 

8.4.2  Management  Functions  and  Services 

(Refer  to  the  Working  Implementation  Agreements  Document) 

8.4.3  ManaQement  information 

^eHm  to  Ujo  Working  implementation  Agreements  Dooumer*.) 

ANNEX  A  -  Management  Information  Library  (MIU 
(Refer  to  the  Working  Implementation  Agreements  Document.) 
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ANNEX  B  -  NMSIG  Object  Identifiers 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
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Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Manufacturing  Message 
Specification  (MMS)  Special  Interest  Group  (MMSSIG)  of  the  National  Institute  of  Standards  and  Technology 
(NIST)  Workshop  for  Implementors  of  Open  Systems  Interconnection  (OSI).  See  Procedures  Manual  for 
Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-nnentioned  Workshop. 
Significant  technical  change  has  occurred  in  this  part  since  it  was  previously  presented. 
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Part  20  -  Manufacturing  Message  Specification  (MMS) 


0  Introduction 

This  section  defines  Implementors  Agreennents  based  on  Manufacturing  Message  Specification  (MMS),  as 
defined  in  ISO/IEC  9506.  ISO/IEC  9506  lias  two  parts.  Part  1  defines  the  Virtual  Manufacturing  Device 
(VMD),  its  subordinate  abstract  objects,  and  the  services  on  these  objects.  Part  2  defines  the  protocol. 
Future  parts  may  define  companion  standards. 

MMS,  as  described  in  ISO/IEC  9506,  is  based  on  the  following  ISO  documents:  ACSE  Service  and  Protocol 
(ISO  8649,  ISO  8650),  Presentation  Service  and  Protocol  (ISO  8822.  ISO  8823),  ASN.1  Abstract  Syntax 
Notation  and  Basic  Encoding  Rules  (ISO  8824,  ISO  8825),  and  Session  Service  and  Protocol  (ISO  8326,  ISO 
8327).  These  services  and  protocols  are  defined  architecturally  in  the  OSI  Reference  Model  (ISO  7498). 
These  agreements  provide  detailed  guidance  for  the  Implementor,  and  eliminate  ambiguities  in 
interpretations. 

An  A-Profile  based  on  MMS  and  these  agreements  can  be  used  over  any  T-Profile  (see  ISO  TR  10000) 
specifying  the  OSI  connection-mode  transport  service,  or  the  transport  profiles  used  in  support  of  MAP 
(Manuifacturing  Automation  Protocol),  TOP  (Technical  and  Office  Protocols),  or  US  GOSIP. 


1  Scope 


2     Field  of  Application 


2.1  General 

Work  on  implementation  agreements  will  proceed  in  phases  based  upon  grouping  of  services  and/or 
contexts.  Implementations  are  not  constrained  from  implementing  services  or  contexts  not  addressed  by 
the  current  set  of  stable  agreements.  Future  phases  of  worl<  may  affect  such  implementations. 


2.2      Phase  1  agreements 

These  agreements  will  be  based  on  a  subset  of  MMS  services  and  protocol  listed  in  table  1  and  defined  in 
ISO/IEC  9506-1  and  ISO/IEC  9506-2. 
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. Tablet  Phase  1  Services 


Initiate 
Conclude 
Reject 
Abort 

Status 

GetNameList 

Identify 

UnsolicitedStatus 
GetCapabilityList 

Ini  t  i  at eDownloadSequence 

DownloadSegment 

TerminateDownloadSequence 

InitiateUploadSequence 

UploadSegment 

TerminateUploadSequence 

DeleteDomain 

GetDomainAt tributes 

Read 
Write 

InformationReport 

GetVar  i  ableAccessAt t r  ibutes 

Input 
Output 

CreateProgramlnvocat  ion 

DeleteProgramlnvocation 

Start 

Stop 

Resume 

Reset 

Kill 

Get ProgramlnvocationAt tributes 


3     Normative  References 

ISO/IEC  9506-1 : 1990  -  Industrial  automation  systems  -  Manufacturing  Message  Specification  Part  1 :  Service 
definition 
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ISO/IEC  9506-2:  1990  -  Industrial  automation  systems  -  Manufacturing  Message  Specification  Part  2: 
Protocol  specification 


4  Definitions 

The  definitions  given  In  ISO/IEC  9506-1  are  applicable  to  this  document. 
In  addition  the  following  definitions  are  used  in  this  document: 


-  MMS  Implementation  -  a  term  used  to  describe  a  system  which  conforms  to  ISO/IEC 
9506,  acting  either  as  client  or  server,  when  it  is  unnecessary  to  distinguish  between  the 
MMS-user  and  the  MMS-provider. 

-  MMSpdu  -  Any  valid  value  of  the  MMSpdu  abstract  data  type  as  defined  in  Clause  7 
of  ISO/IEC  9506-2,  except  fortheinitiate-RequestPDU,  initiate-ResponsePDU,  and  initiate- 
ErrorPDU  choices,  encoded  in  the  negotiated  transfer  syntax. 


5     Corrigenda  and  addenda 

(Refer  to  Working  Agreements,  Dated  December,  1990.) 


6  Status 

(Refer  to  Working  Agreements,  Dated  December,  1990.) 


7    General  agreements 


7.1      Max  supported  PDU  size 

The  max_mms_pdu_size  is  defined  as  the  maximum  number  of  octets  in  an  MMSpdu  encoded  using  the 
negotiated  transfer  syntax.  This  size  shall  apply  to  all  MMSpdu's  with  the  exception  of  the  initiate-Request 
PDU,  initiate-Response  PDU,  and  initiate-Error  PDU.  The  max_mms_pdu_size  shall  be  negotiated  during 
connection  initiation  using  the  Local  Detail  Calling  and  Local  Detail  Called  parameters  of  the  MMS  initiate 
service. 

The  negotiated  max_mms_pdu_size  shall  be  applied  as  follows: 
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-  Any  received  MMSpdu  whose  length  is  less  than  or  equal  to  the  negotiated 
max_mms_pdu_size  shall  be  properly  parsed  and  processed. 


-  An  MMS  implementation  should  not  send  an  MMSpdu  whose  size  exceeds  the 
negotiated  max_mms_pdu_size.  If  an  MMS  implementation  sends  an  MMSpdu  that 
exceeds  the  negotiated  max_mms_pdu_size,  then  it  shall  be  prepared  to  receive  a  reject 
pdu.  Should  an  MMS  implementation  receive  an  MMSpdu  that  exceeds  the  negotiated 
max_mms_pdu_size,  it  shall  either  reject  the  MMSpdu  or  accept  the  MMSpdu  as  if  no 
size  violation  had  occurred  and  perform  the  expected  processing. 

-  If  an  MMS  implementation  is  unable  to  send  a  service  response  because  the  response 
would  exceed  the  max_mms_pdu_size,  then  it  shall  return  a  Service  response  (-)  with  an 
error  class  of  SERVICE  and  an  error  code  of  OTHER. 

-  When  rejecting  an  MMSpdu  because  it  exceeds  the  negotiated  max_mms_pdu_size, 
an  MMS  implementation  shall  use  a  Reject  PDU  Type  of  PDU-ERROR  and  a  Reject  Code 
of  INVALID-PDU  in  the  resulting  reject  pdu. 


7.2  FileName 

Restrictions  for  the  use  of  the  type  FileName  in  the  MMS  Abstract  Syntax  are  specified  in  section  9.1  of  part 
9  of  these  agreements. 


3     Service-specific  agreements 


8.1      Environment  and  general  management 


8.1.1  Initiate 


8.1.1.1         Negotiation  of  MMS  abstract  syntaxes 

On  the  A-ASSOCIATE  response,  the  MMS  responder  shall  not  accept  more  than  one  presentation  context 
derived  from  an  MMS  abstract  syntax.  For  this  agreement,  the  term  'MMS  abstract  syntax'  shall  represent 
an  abstract  syntax  from  the  set  containing  the  abstract  syntax  defined  in  clause  19  of  ISO/lEC  9506-2  and 
abstract  syntaxes  defined  by  MMS  companion  standards. 

NOTE  -  There  are  technical  problems  with  describing  operation  in  multiple  MMS  abstract  syntaxes  over  a 
single  association.  These  problems  have  been  identified  as  of  9/90,  and  form  the  basis  of  the  prior  agreement. 
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8.1 .1 .2        Max  serv  outstanding 

An  MMS  Implementation  which  intends  to  conform  only  with  the  Client  Conformance  Requirements  for 
Requester  CBBs  shall: 

a)  propose  one  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Called 
parameter  in  the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  one  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Calling 
parameter  in  the  Initiate  service  when  receiving  the  application  association  initiation 
(called). 

An  MMS  Implementation  which  intends  to  conform  to  one  or  more  Server  Conformance  Requirements  for 
Responder  CBBs  shall: 

a)  propose  one  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Calling 
parameter  in  the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  one  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Called 
parameter  in  the  Initiate  service  when  receiving  the  application  association  initiation 
(called). 


8.1.1.3        Local  detail  calling 

The  local  detail  calling  parameter  in  the  initiate  request  primitive  shall  specify  the  max_mms_pdu_size 
guaranteed  to  be  supported  by  the  calling  MMS  implementation.  If  the  local  detail  calling  parameter  is 
absent  from  the  request  primitive,  then  the  calling  MMS  implementation  guarantees  support  for  an  unlimited 
max_mms_pdu_size. 

If  present  in  the  request  or  indication  primitives,  the  local  detail  calling  parameter  shall  not  be  less  than  64; 
however,  it  is  recommended  that  at  least  512  octets  be  supported. 


8.1.1.4        Local  detail  called 

The  local  detail  called  parameter  in  the  initiate  response  shall  specify  the  negotiated  max_mms_pdu_size 
for  the  application  association. 

If  the  local  detail  calling  parameter  was  omitted  in  the  indication  primitive,  then  the  local  detail  called 
parameter: 

a)  may  be  omitted  from  the  response,  indicating  that  the  calling  MMS  implementation 
and  the  called  MMS  implementation  are  prepared  to  support  an  unbounded 
max_mms_pdu_size; 
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b)  may  be  specified  in  the  response,  indicating  a  requirement  to  support  the  specified 
value  for  max_mms_pdu_size. 

If  the  local  detail  calling  parameter  was  included  in  the  request,  then  this  parameter  shall  be  present  in  the 
response  and  its  value  shall  be  less  than  or  equal  to  the  value  of  the  local  detail  calling  parameter  of  the 
request. 

If  present  in  the  response,  the  local  detail  called  parameter  shall  not  be  less  than  64;  however,  It  Is 
recommended  that  at  least  512  octets  be  supported. 


8.2      VMD  support 


8.3      Domain  management 


8.3.1       List  of  capabilities 

Only  one  capability  shall  be  described  in  each  Visible  String  of  the  SEQUENCE  OF. 


8.3.2       Initiate  Download  Sequence  service 

The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 

The  syntax  and  semantics  of  the  capabilities  shall  be  defined  by  the  Server  in  the  PICS.  Any  deviation  from 
the  defined  syntax  and  semantics  shall  be  grounds  for  the  Server  to  return  a  service  error  with  Error  Class 
=  RESOURCE  and  Error  Code  =  CAPABILITY-UNKNOWN. 


8.3.3       Download  Segment  service 

A  client  that  receives  a  Download  Segment  indication  after  issuing  a  Download  Segment  Result(+)  with  the 
MoreFollows  parameter  equal  to  FALSE  or  after  issuing  a  Download  Segment  Result(-)  shall  issue  either  a 
service  error,  specifying  an  Error  Class  =  SERVICE  and  an  Error  Code  =  PRIMITIVES-OUT-OF-SEQUENCE, 
or  an  Abort  request. 


8.3.4       Terminate  Download  Sequence  service 

If  a  client  receives  a  Terminate  Download  Sequence  indication  in  which  the  Discard  parameter  is  absent  and 
the  client  has  not  issued  a  Download  Segment  response  with  the  More  Follows  parameter  =  FALSE  for  that 
Domain,  it  shall  behave  as  If  it  had  received  a  Terminate  Download  Sequence  indication  with  the  Discard 
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parameter  present  with  error  class  =  VMD-STATE  and  error  code  =  DOMAIN-TRANSFER-PROBLEM.  It  Is 
then  up  to  the  client  application  to  determine  the  true  state  of  the  Domain  and  take  any  recovery  action. 


8.3.5       Initiate  Upload  Sequence  service 

The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 


8.3.6       Upload  Segment  service 

A  server  that  receives  an  Upload  Segment  indication  for  an  Upload  State  Machine  for  which  it  has  issued 
an  Upload  Segment  Resuit(-)  or  an  Upload  Segment  Result(+)  with  the  MoreFollows  parameter  equal  to 
FALSE,  shall  issue  either  a  service  error,  specifying  an  Error  Class  =  SERVICE  and  an  Error  Code  = 
PRIMITIVES-OUT-OF-SEQUENCE,  or  an  Abort  request. 


8.3.7  Get  Domain  Attributes  service 

The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 

8.3.8  Get  Capability  List  service 

The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 


8.4      Program  Invocation  management 


8.4.1       start  service 


A  ProgramlnvocationState  of  non-existent  shall  be  returned  in  a  Result(-)  when  a  request  to  Start  a  non- 
existent Program  Invocation  is  received. 


8.4.2       Stop  service 

A  ProgramlnvocationState  of  non-existent  shall  be  returned  in  a  Result(-)  when  a  request  to  Stop  a  non- 
existent Program  Invocation  is  received. 
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8.4.3  Resume  service 

A  ProgramlnvocationState  of  non-existent  shall  be  returned  in  a  Result(-)  when  a  request  to  Resume  a  non- 
existent Program  Invocation  is  received. 

8.4.4  Reset  service 

A  ProgramlnvocationState  of  non-existent  shall  be  returned  in  a  Result(-)  when  a  request  to  Reset  a  non- 
existent Program  Invocation  is  received. 


It  is  strongly  recommended  that  for  services  which  use  variable  access,  a  Variable  List  Name  or  List  of 
Variable  be  used  instead  of  Scattered  Access. 

No  implementations  shall  be  required  to  propose  or  accept  the  VSCA  Parameter  CBB. 

8.5.2       Fioating  point 

It  is  strongly  recommended  for  services  which  use  floating  point  types  or  values,  that  the  choice  of  floating- 
point in  the  Data  and  TypeSpecification  productions  be  used  instead  of  the  real  choice. 

No  implementations  shall  be  required  to  propose  or  accept  the  REAL  parameter  CBB. 

8.6  Semaphore  management 

Semaphore  services  are  not  considered  in  Phase  1 . 

8.7  Operator  communication 

No  Operator  Communication  agreements  have  been  identified  to  date. 


8.5 


Variable  access 


8.5.1 


Scattered  access 
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8.8  Event  management 

Event  Management  services  are  not  considered  in  Phase  1. 

8.9  Journal  management 

Journal  Management  services  are  not  considered  in  Phase  1 


December  1990  (Stable) 
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Annex  A  (normative) 


Backwards  compatibility  agreements 
A.I  Introduction 

There  Is  an  installed  base  of  real  DIS  9506  based  implementations.  Providing  support  for  application 
connectivity  to  both  DIS  and  IS  is  desired  as  a  migration  strategy.  These  implementation  agreements  will 
allow  IS  based  implementations  to  interoperate  with  DIS  based  implementations  as  described  in  ANNEX  B. 
To  achieve  this  backwards  compatibility,  the  IS  implementation  shall  support  all  of  the  agreements  in  this 
section. 

It  was  found  that  the  Abstract  Syntax  name  object  identifiers  of  both  DIS  and  IS  were  identical.  Therefore, 
the  use  of  zero  as  the  version  number  allows  differentiation  between  an  IS  and  a  DIS  based  implementation. 
Since  the  abstract  syntax  name  object  identifier  of  any  companion  standard  is  different  from  that  used  by 
the  DIS  implementations,  DIS  implementations  cannot  interoperate  with  IS  based  implementations  in  a 
companion  standard  context.  ■ 


1  The  value  of  zero  is  a  valid  value  for  this  parameter  in  the  DIS  and  not  in  the  IS. 

2  There  are  three  types  of  implementations  when  considering  MMS  backwards  compatibility. 

IMP-1:  An  implementation  based  on  DIS  9506  as  described  in  Annex  B; 

IMP-2:  An  implementation  based  on  IS  9506  with  no  backwards  compatibility  agreements 


IMP-3:  An  implementation  based  on  IS  9506  which  includes  the  backwards  compatibility 
agreements  of  this  annex.  Such  an  implementation  can  dynamically  negotiate  to 
interoperate  with  an  IMP-1,  an  IMP-2,  or  an  IMP-3  implementation. 

Since  the  value  of  the  minor  version  number  is  zero  for  DIS-based  implementations,  and  is  one 
or  greater  for  implementations  of  ISO/I  EC  9506,  this  value  can  be  used  to  differentiate  between 
IMP-1  and  IMP-2.  An  IMP-3  system  can  interoperate  with  either  of  these  systems.  If  an  IMP-3  is 


the  Calling  system,  it  will  offer  a  value  of  one  (or  greater)  for  the  proposed  version  number.  An  i 


IMP-1  system  will  respond  with  a  value  of  the  negotiated  version  number  of  zero,  using  the 
negotiation  procedure  defined  in  ISO/IEC  9506.  The  IMP-3  system  will  accept  this  response.  If 
the  IMP-3  system  is  the  Called  system  and  has  received  an  Initiate  request  with  a  value  of  zero 
for  the  proposed  version  number  (from  an  IMP-1  system),  it  will  respond  with  a  value  of  zero  for 
the  negotiated  version  number.  By  following  this  procedure,  an  IMP-3  can  interoperate  with  an 
IMP-2  or  with  another  lMP-3  viewed  as  an  IMP-2.  After  association  context  establishment,  an 
IMP-3  system  shall  behave  as  either  an  IMP-1  or  an  IMP-2  system  as  appropriate  on  that 


NOTES 


applied; 


10 


.1 


PART  20  -  MMS  December  1 990  (Stable) 

particular  association.  The  remainder  of  this  section  describes  additional  agreements  which 
change  an  IMP-2  implementation  into  an  IMP-3  implementation. 

A.2      Backwards    compatibility    agreements    for    calling  MMS 
implementations 

A  calling  MMS  implementation  shall  be  capable  of  receiving  and  supporting  a  negotiated VersionN umber 
parameter  in  the  Initiate  Sen/ice  confirm  of  zero. 

A  calling  MMS  implementation  which  has  received  a  negotiatedVersionNumber  parameter  in  the  Initiate 
Service  confirm  of  zero  shall  support  the  modifications  described  in  A.4. 

A  calling  MMS  implementation  shall  be  capable  of  receiving  an  Application  Context  Name  parameter  value 
appropriate  to  an  IMP-1  or  IMP-2  in  the  A-Associate  confirm. 

A  calling  MMS  implementation  which  has  received  a  negotiatedVersionNumber  of  zero  shall  be  capable  of 
receiving  and  supporting  an  Initiate  Response  which  has  been  encoded  according  to  the  modifications 
described  in  Appendix  B,  specifically  the  capability  of  receiving  and  supporting  a  negotiatedParameterCBB 
containing  exactly  7  bits. 

If  a  calling  MMS  implementation  receives  an  Initiate  confirm  primitive  with  a  negotiatedVersionNumber 
parameter  equal  to  zero,  the  calling  MMS  implementation  shall  support  the  VLIS  conformance  building  block 
if  the  implementation  claims  support  for  any  service  which  contains  one  or  more  parameters  which  indicate 
the  VLIS  CBB  in  its  service  definition. 


A.3      Backwards    compatibility    agreements    for    called  MMS 
implementations 

A  called  MMS  implementation  shall  be  capable  of  receiving  and  supporting  a  proposedVersionNumber 
parameter  in  the  Initiate  Sen/ice  indication  of  zero. 

A  called  MMS  implementation  which  has  received  a  proposedVersionNumber  parameter  in  the  Initiate 
Service  indication  of  zero  shall  support  the  modifications  in  A.4. 

A  called  MMS  implementation  shall  be  capable  of  receiving  an  Application  Context  Name  parameter 
appropriate  to  an  IMP-1  or  IMP-2  in  the  A-Associate  indication. 

A  called  MMS  implementation  shall  be  capable  of  receiving  and  supporting  an  Initiate  Request  which  has 
been  encoded  according  to  the  modifications  described  in  Appendix  B,  specifically  the  capability  of  receiving 
and  supporting  a  proposedParameterCBB  containing  exactly  7  bits. 

If  a  called  MMS  Implementation  receives  an  Initiate  indication  primitive  with  a  proposedVersionNumber 
parameter  equal  to  zero,  the  called  MMS  implementation  shall  support  the  VLIS  conformance  building  block 
if  the  implementation  claims  support  for  any  sen/ice  which  contains  one  or  more  parameters  which  indicate 
the  VLIS  CBB  in  its  service  definition. 
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A.4     General  backwards  compatibility  agreements 


A.4.1       VMD  logical  status 

If  the  current  VMD  State  is  SUPPORT-SERVICES-ALLOWED  and  the  association  minor  version  number  is 
zero,  then  the  vmdLogicalStatus  parameter  shall  have  a  value  of  STATE-CHANGES-ALLOWED  in  a  Status 
response  or  in  an  unsolicitedStatus  request. 
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Annex  B  (normative) 

DIS  9506  modifications  required  for  backwards  compatibility 
B.1  Introduction 

This  annex  is  an  integral  part  of  this  part.  It  documents  the  modifications  to  DIS  9506  required  to  describe 
implementations  for  which  the  agreements  of  this  part  provide  backwards  compatibility.  This  annex  as 
applied  to  DiS  9506  is  referred  to  as  Version  0. 

B.2  References 

[1]  MMS/1  Manufacturing  Message  Specification  -  ISO  DIS  9506  -  Sen/ice  Definition,  December  1987 
[2]  MMS/2  Manufacturing  Message  Specification  -  ISO  DIS  9506  -  Protocol  Specification,  December  1987 
[3]  NBS  OSI  Implementors  Workshop  Agreements  -  December  1987 

B.3  General 

B.3.1       Implementation  base 

Version  0  is  based  upon  Reference  [3]  in  B.2  as  it  applies  to  MMS. 

B.3.2       Rules  of  extensibility 

The  following  sentence  is  appended  to  the  last  paragraph  in  section  8.2.1.1.5.2  Proposed  Parameter  CBB 
and  the  last  paragraph  in  section  8.2.1.2.5.2  Negotiated  Parameter  CBB  of  DIS  9506-1. 

"Any  additional  bits  shall  be  ignored." 

B.4     Modifications  to  the  protocol  definitions 

B.4.1       Page  39,  Section  7.5.2  of  DIS  9506-2 

CHANGE 
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reportEventEnrollmentStatus   [60]  IMPLICIT  ReportEventEnrollmentStatus-Request, 

TO 

reportEventEnrollmentStatus   [60]  ReportEventEnrollmentStatus-Request, 
B.4.2       Page  49,  Section  7.6.4,  DIS  9506-2 

CHANGE 

ApplicationReference  ::=  SEQUENCE  { 

ap-title  ISO-8650-ACSE-1.AP-title  OPTIONAL, 

ap-invocation-id  ISO-86  50-ACSE-1  .AP-invocation-id  OPTIONAL, 

ae-qualifier  ISO-8650-ACSE-1  .AE-quallfier  OPTIONAL, 

ae-invocation-id  ISO-8650-ACSE-1  .AE-invocation-id  OPTIONAL 
} 


TO 


ApplicationReference  ::=  SEQUENCE  { 
ap-title  [0]  OBJECT  IDENTIFIER  OPTIONAL, 

ap-invocation-id  [1]  INTEGER  OPTIONAL, 
ae-qualifier  [2]  INTEGER  OPTIONAL, 

ae-invocation-id        [3]  INTEGER  OPTIONAL 
} 


B.4.3       Page  95,  Section  12.2.1  of  DIS  9506-2 

CHANGE 

structure   [2|  IMPLICIT  SEQUENCE  OF  SEQUENCE  { 

TO 

structure   [2]  IMPLICiT  SEQUENCE  { 

B.4.4       Page  96,  Section  12.3.1  of  DIS  9506-2 

CHANGE 

named     [4]  IMPLICIT  SEQUENCE  { 

TO 
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named     [5]  IMPLICIT  SEQUENCE  { 

B.4.5       Page  98,  Section  12.4.2  of  DIS  9506-2 

CHANGE 

generalized-time   [10]  IMPLICIT  General izedTime, 

TO 

generalized-time   [11]  IMPLICIT  GeneralizedTime, 
B.4.6       Page  138,  Section  15.14  of  DIS  9506-2 

CHANGE 

additionalDetail  [9]  IMPLICIT  EE-Additional-Detail  OPTIONAL 

TO 

additionalDetail  [9]  EE-Additional-Detail  OPTIONAL 

B.4.7       Page  166,  Section  17.10  of  DIS  9506-2 

CHANGE  the  transfer  syntax  object  identifier  value  from 
{  iso  asn1(1)  basic-encoding(l)  } 

TO 

{  joint-iso-ccitt  asn1(1)  basic-encoding(l)  } 

B.5     Behavioral  requirements 
B.5.1  Filenames 

File  Names  are  specified  in  accordance  with  the  NBS  Implementors'  agreements  for  FTAM  Reference  [3] 
in  B.2. 
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B.5.2       Identify  service 

In  the  Identify  service,  the  vendor,  model  and  revision  fields  may  be  of  any  length,  but  only  the  first  64,  16, 
and  1 6  octets  respectively  are  treated  as  significant. 


B.5.3       Initiate  service 

An  MMS  Client  will: 

a)  propose  1  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Called 
parameter  in  the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  1  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Calling 
parameter  in  the  Initiate  service  when  receiving  the  application  association  initiation 
(called). 

An  MMS  Server  will: 


a)  propose  1  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Calling 
parameter  in  the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  1  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Called 
parameter  in  the  Initiate  service  when  receiving  the  application  association  initiation 
(called). 


B.5.3.1        Minimum  segment  size 

MMS  implementations  are  able  to  parse  and  process  512  octets  of  MMSpdu  as  they  are  encoded  in  ASN.1 
basic  encoding  rules. 


B.5.3.2        Maximum  segment  size 

The  Max  Segment  Size  is  defined  as  the  maximum  number  of  octets  in  an  MMSpdu  encoded  using  the 
negotiated  transfer  syntax.  This  size  will  apply  to  all  MMSpdu's  with  the  exception  of  the  initiate-Request 
PDU,  initiate-Response  PDU,  and  the  initiate-Error  PDU.  The  max  segment  size  will  be  negotiated  during 
connection  initiation  using  the  Proposed  Max  Segment  Size  and  Negotiated  Max  Segment  Size  parameters 
of  the  MMS  initiate  service. 

The  Max  Segment  Size  will  be  applied  as  follows: 
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-  Any  received  MMSpdu  which  is  less  than  or  equal  to  the  Max  Segment  Size  will  be 
properly  parsed  and  processed; 

-  An  MMS  implementation  will  not  send  an  MMSpdu  whose  size  exceeds  the  Max 
Segment  Size. 

B.5.4       Abstract  syntax  name 

The  ASN.1  object  identifier  value  for  the  abstract  syntax  name  will  be  the  same  as  specified  on  page  166, 
section  17.10  of  DIS  9506-2. 

B.5.5       Application  context  name 

The  ASN.1  object  identifier  value  for  the  application  context  name  will  be  the  same  as  specified  on  page  1 66, 
section  17.11  of  DIS  9506-2. 

An  MMS  implementation  ignores  the  Application  Context  Name  In  the  A-Associate  indication  and  the  A- 
Associate  confirm. 

B.5.6       Minor  version  number 

The  Minor  Version  Number  is  zero. 

B.6     Parameter  CBB  subset 

The  following  subset  of  MMS  Parameter  CBBs  were  considered  during  preparation  of  this  annex: 

-  STR1; 

-  NEST; 

-  VADR; 

-  VNAM. 

B.7     Service  subset 

The  following  subset  of  MMS  services  were  considered  during  preparation  of  this  annex. 
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Table  2  -  MMS  Service  Subset 


Initiate 
Conclude 
Cancel 
Status 
GetNameList 
Identify 
Unsol i ci tedStatus 
Ge t Capab  ilityList 
InitiateDownloadSequence 

DownloadSegment 
TerminateDownloadSequence 
InitiateUploadSequence 

UploadSegment 
TerminateUploadSequence 
Reque  s  t  Doma  i  nDown load 
Reques  t Doma  i  nUpload 
LoadDoma  i  nCon t  en t 
StoreDomainContent 

DeleteDomain 
GetDomainAttributes 
Read 

Write  ' 
InformationReport 
GetVariableAccessAt tributes 
Input 


Output 
TakeControl 
Rel inqu  i  shCont  rol 
ReportSemaphoreStatus 
ReportPoolSemaphoreStatus 
ReportSemaphoreEntryStatus 
CreateProgr amlnvocat  ion 
DeleteProgramlnvocat  ion 
Start 
Stop 
Resume 
Reset 
Kill 

GetProgreunlnvocationAt  tributes 
ObtainFile 
Get Event Cond  i  t  i  onAt  t  r  i  bu t  es 
ReportEventConditionStatus 
Get Alarms ummary 
ReadJournal 
WriteJournal 
InitializeJournal 
CreateJournal 
DeleteJournal 
Report JournalStatus 
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This  document  records,  in  replacement  page  format,  all  changes  to  stable  material  wliicii  was  current 
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SP  500-183,  Version  4,  Edition  1.  By  following  the  instructions  below,  and  replacing  or  inserting  the 
indicated  pages,  text  will  be  created  which  reflects  the  current  status  of  relevant  stable  material  as  of  June 
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If  there  are  redllf^e  or  strikeout  in  the  Table  of  Contents,  then  that  document  should  contain  the  replacement 
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The  following  table  gives  all  necessary  information.  Entries  in  the  first  column  indicate  that  those  pages  are 
to  be  replaced  with  the  pages  referenced  in  the  second  column. 

The  instructions  below  are  given  by  Chapter  and  Page  number,  referring  to  NIST  SP  500-183.  The  changes 
made  are  indicated  by  redline  and  strikeout  on  the  pages  where  the  changes  occur,  and  all  the  replacement 
pages  are  dated  in  the  upper  right-hand  corner  for  easy  identification. 

Changes  on  replacement  pages  are  Errata  (technical,  alignment,  editorial,  or  other).  The  term  "other"  may 
include  addition  of  new  stable  functionality.  All  changes  apply  to  the  previous  version  and  edition. 
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1 .  deletion  of  material  (strike  out) 

2.  insertion  of  new  material  (redllnte-^shaded  Wi^ds  cr  sentter^ces),  and 

3.  replacement  of  old  text  with  new  text  (combination  of  (1)  and  (2)  above. 

Technical  errata  are  changes  from  implementor  experience  which  materially  affect  the  meaning  or  semantics 
of  a  section,  and  editorial  changes  do  not  change  semantics.  Alignment  changes  are  material  changes 
made  in  the  interest  of  international  harmonization  and  evolving  base  standards. 

In  general,  technical  errata  are  more  "severe"  than  editorial  errata,  and  alignment  errata  are  more  "severe" 
than  technical  errata.  If  a  particular  replacement  has  a  combination  of  errata,  the  most  "severe"  errata  will 
be  checked  in  the  replacement  page  table.  Readers  should  keep  in  mind  that  these  errata  may  be  further 
categorized  in  future  editions. 
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Stable  Implementation 
Agreements  for  Open  Systems 
Interconnection  Protocols: 
Part  1  -  General  Information 


Output  from  the  June  1991  NIST  Workshop 
Implementors  of  OSI 


Chair/Editor,  OIW  Workshop:  Tim  Boland 

Workshop  Editor:  Brenda  Gray 


Part  1  -  General  Information 


June  1991  (Stable) 


Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Chair  of  the  National  Institute  of 
Standards  and  Technology  (NIST)  Workshop  for  Implementors  of  Open  Systems  Interconnection  (OSI). 

This  part  replaces  the  previously  existing  chapter  on  this  subject.  There  is  no  significant  technical  change 
from  this  text  as  previously  given. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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This  document  records,  in  replacement  page  format,  all  changes  to  stable  material  which  was  current 
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indicated  pages,  text  will  be  created  which  reflects  the  current  status  of  relevant  stable  material  as  of  March 
15,  1991. 

If  there  are  redline  or  strikeout  in  the  Table  of  Contents,  then  that  document  should  contain  the  replacement 
pages  for  March  1991.  THIS  INSERT  SET  SHOULD  BE  SAVED. 

The  following  table  gives  all  necessary  information.  Entries  in  the  first  column  indicate  that  those  pages  are 
to  be  replaced  with  the  pages  referenced  in  the  second  column. 

The  instructions  below  are  given  by  Chapter  and  Page  number,  referring  to  NIST  SP  500-183.  The  changes 
made  are  indicated  by  redline  and  strikeout  on  the  pages  where  the  changes  occur,  and  all  the  replacement 
pages  are  dated  in  the  upper  right-hand  corner  for  easy  identification. 

Changes  on  replacement  pages  are  Errata  (technical,  alignment,  editorial,  or  other).  The  term  "other"  may 
include  addition  of  new  stable  functionality.  All  changes  apply  to  the  previous  version  and  edition. 
Replacements  reflect  the  following  types  of  changes: 

1 .  deletion  of  material  (striko  out) 

2.  insertion  of  new  material  (redline-shadGd  words  or  sentences),  and 

3.  replacement  of  old  text  with  new  text  (combination  of  (1)  and  (2)  above. 

Technical  errata  are  changes  from  implementor  experience  which  materially  affect  the  meaning  or  semantics 
of  a  section,  and  editorial  changes  do  not  change  semantics.  Alignment  changes  are  material  changes 
made  in  the  interest  of  international  harmonization  and  evolving  base  standards. 

In  general,  technical  errata  are  more  "severe"  than  editorial  errata,  and  alignment  errata  are  more  "severe" 
than  technical  errata.  If  a  particular  replacement  has  a  combination  of  errata,  the  most  "severe"  errata  will 
be  checked  in  the  replacement  page  table.  Readers  should  keep  in  mind  that  these  errata  may  be  further 
categorized  in  future  editions. 
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Technical  Publications 

Periodical 


Journal  of  Research  of  the  National  Institute  of  Standards  and  Technology— Reports  NIST  research 

and  development  in  those  disciplines  of  the  physical  and  engineering  sciences  in  which  the  Institute 
is  active.  These  include  physics,  chemistry,  engineering,  mathematics,  and  computer  sciences. 
Papers  cover  a  broad  range  of  subjects,  with  major  emphasis  on  measurement  methodology  and 
the  basic  technology  underlying  standardization.  Also  included  from  time  to  time  are  survey  articles 
on  topics  closely  related  to  the  Institute's  technical  and  scientific  programs.  Issued  six  times  a  year. 


Nonperiodicals 


Monographs — Major  contributions  to  the  technical  literature  on  various  subjects  related  to  the 
Institute's  scientific  and  technical  activities. 

Handbooks — Recommended  codes  of  engineering  and  industrial  practice  (including  safety  codes)  de- 
veloped in  cooperation  with  interested  industries,  professional  organizations,  and  regulatory  bodies. 
Special  Publications — Include  proceedings  of  conferences  sponsored  by  NIST,  NIST  annual  reports, 
and  other  special  publications  appropriate  to  this  grouping  such  as  wall  charts,  pocket  cards,  and 
bibliographies. 

Applied  Mathematics  Series — Mathematical  tables,  manuals,  and  studies  of  special  interest  to  physi- 
cists, engineers,  chemists,  biologists,  mathematicians,  computer  programmers,  and  others  engaged  in 
scientific  and  technical  work. 

National  Standard  Reference  Data  Series — Provides  quantitative  data  on  the  physical  and  chemical 
properties  of  materials,  compiled  from  the  world's  literature  and  critically  evaluated.  Developed  un- 
der a  worldwide  program  coordinated  by  NIST  under  the  authority  of  the  National  Standard  Data 
Act  (Public  Law  90-396).  NOTE:  The  Journal  of  Physical  and  Chemical  Reference  Data  (JPCRD) 
is  published  quarterly  for  NIST  by  the  American  Chemical  Society  (ACS)  and  the  American  Insti- 
tute of  Physics  (AIP).  Subscriptions,  reprints,  and  supplements  are  available  from  ACS,  1155  Six- 
teenth St.,  NW.,  Washington,  DC  20056. 

Building  Science  Series— Disseminates  technical  information  developed  at  the  Institute  on  building 
materials,  components,  systems,  and  whole  structures.  The  series  presents  research  results,  test 
methods,  and  performance  criteria  related  to  the  structural  and  environmental  functions  and  the 
durability  and  safety  characteristics  of  building  elements  and  systems. 

Technical  Notes — Studies  or  reports  which  are  complete  in  themselves  but  restrictive  in  their  treat- 
ment of  a  subject.  Analogous  to  monographs  but  not  so  comprehensive  in  scope  or  definitive  in 
treatment  of  the  subject  area.  Often  serve  as  a  vehicle  for  final  reports  of  work  performed  at  NIST 
under  the  sponsorship  of  other  government  agencies. 

Voluntary  Product  Standards — Developed  under  procedures  published  by  the  Department  of  Com- 
merce in  Part  10,  Title  15,  of  the  Code  of  Federal  Regulations.  The  standards  establish  nationally 
recognized  requirements  for  products,  and  provide  all  concerned  interests  with  a  basis  for  common 
understanding  of  the  characteristics  of  the  products.  NIST  administers  this  program  as  a  supplement 
to  the  activities  of  the  private  sector  standardizing  organizations. 

Consumer  Information  Series — Practical  information,  based  on  NIST  research  and  experience,  cov- 
ering areas  of  interest  to  the  consumer.  Easily  understandable  language  and  illustrations  provide  use- 
ful background  knowledge  for  shopping  in  today's  technological  marketplace. 
Order  the  above  NIST  publications  from:  Superintendent  of  Documents,  Government  Printing  Office, 
Washington,  DC  20402. 

Order  the  following  NIST  publications— FITS  and  NISTIRs—from  the  National  Technical  Information 
Service,  Springfield,  VA  22161. 

Federal  Information  Processing  Standards  Publications  (FTPS  PUB)— Publications  in  this  series  col- 
lectively constitute  the  Federal  Information  Processing  Standards  Register.  The  Register  serves  as 
the  official  source  of  information  in  the  Federal  Government  regarding  standards  issued  by  NIST 
pursuant  to  the  Federal  Property  and  Administrative  Services  Act  of  1949  as  amended,  Public  Law 
89-306  (79  Stat.  1127),  and  as  implemented  by  Executive  Order  1 1717  (38  FR  12315.  dated  May  11, 
1973)  and  Part  6  of  Title  15  CFR  (Code  of  Federal  Regulations). 

NIST  Interagency  Reports  (NISTIR)— A  special  series  of  interim  or  final  reports  on  work  performed 
by  NIST  for  outside  sponsors  (both  government  and  non-government).  In  general,  initial  distribu- 
tion is  handled  by  the  sponsor;  public  distribution  is  by  the  National  Technical  Information  Service, 
Springfield,  VA  22161,  in  paper  copy  or  microfiche  form. 
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